[dev] Horde_RPC_soap tweaks

[Chuck Hagenbuch]

Quoting John Morrissey <jwm at horde.net>:

> Sure. :-) It handles customer account provisioning and maintenance for the
> Internet portion of a telecom company. Any time an account is created or
> modified, this application is called via SOAP or via customer web sites to
> update the various systems we use to deliver Internet service. It accepts
> transactions from our billing systems to set up new accounts and from
> customers to manage their accounts (password changes, ordering new
> products), to name a few.

Very nice. If you ever want to write up a description of this I'd love  
to put it up on a "what are people doing with Horde" section of the  
website. :)

>> This one I have a gut reaction against, though I certainly see your
>> use case. I'm not sure how widespread that need is, though, and I feel
>> like having more fine-grained control over which methods are exposed,
>> for all backends, would be better. Unlikely that can be done without
>> breaking BC though, so I'm neutral on this for now.
>
> So you're thinking of a programmatic or configurable way to specify which
> API calls are exposed via any/all RPC methods? That would be useful, but to
> handle the use case I mentioned, we'd still need a way to selectively expose
> certain calls *only* via certain endpoints (not backends, endpoints).

Yeah. I guess after thinking about this, I'd rather you passed an  
explicit array of allowed methods in the RPC constructor params  
instead of using a regex. The regex just feels hackish to me, but  
creating a limited server doesn't. How does that sound?

> Applying this setting to all backends is definitely the Right Thing, but
> implementing that is more than I have time for right now. You'll hear no
> complaint from me if you'd rather I not commit this. This was an
> itch-scratching feature. :-)

If it's done as a general parameter it can be implemented for other  
backends later.

> I was torn between _INFO and _DEBUG. On one hand, these logs are a lot like
> web server access logs in that they're useful for after-the-fact
> troubleshooting or usage-pattern profiling ("oh, so the box is 300MB into
> swap because $REMOTE_APPLICATION started throwing 10x the normal SOAP
> transaction load at us"). This use doesn't seem amenable to _DEBUG since
> _DEBUG turns up the verbosity significantly, such as with individual SQL
> queries, which don't seem that useful on an ongoing basis.
>
> Oh, and I forgot to mention that this logging doesn't do a deep array walk
> to log arguments. If any arguments are arrays, the logging will cast them to
> the string Array. I didn't think this was a huge deal since we can never be
> sure how deep an array goes.

Alright, convinced - just as long as the INFO version is really very  
concise. Could have a DEBUG version with more info if necessary.

Thanks,
-chuck