[dev] Horde_RPC_soap tweaks

[Chuck Hagenbuch]

Quoting John Morrissey <jwm at horde.net>:

>> Did you try setting the available methods explicitly in the 'provides'
>> settings in registry.php instead?
>
> Yup. However, Horde_RPC_soap calls Registry::listMethods() with no
> arguments, so all methods are listed.

Seems like a bug - if there are explicit provides entries, we  
shouldn't return other methods, right?

>> This is a feature for pretty advanced users; no reason they can't have
>> their own rpc.php endpoints. Also, it's an addition, not necessary to
>> really hack the existing install.
>
> Any further thoughts on this aspect?

Without further clarification, I'm not sure why having a custom rpc  
endpoint is a bad solution here.

>> > 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?
>
> That sounds decent, unless we decide on a straightforward way of specifying
> API method visibility in api.php (above).

I think instantiating a limited server is still a useful feature.

>> Alright, convinced - just as long as the INFO version is really very
>> concise. Could have a DEBUG version with more info if necessary.
>
> On Tue, May 22, 2007 at 12:30:41AM +0200, Jan Schneider wrote:
>> This is definitely a DEBUG log.
>
> It's fairly concise; here's sample output:
>
> SOAP call: appname/searchAccounts('*', Array) by user at example.com serviced
> in 1 seconds, sent 609 bytes in response
>
> This has been very useful when troubleshooting load problems or when proving
> to other groups that our application is behaving properly. I liken it to
> Apache's access logs; they're highly useful to determine the current and
> past operating state of the machine. Like I mentioned, LOG_DEBUG brings in a
> lot of other verbose logging, like SQL queries, that are substantially less
> useful than the SOAP logging has been for us.

That looks reasonable to me.

>> And is there any reason why you use global vars instead of object
>> properties?
>
> I tried object properties initially, but it seems that something was
> operating on a copy of the Horde_RPC_soap instance, so the data set in
> Horde_RPC_soap::_dispatcher() never made it to Horde_RPC_soap::getResponse()
> for logging. I suspect something in the PEAR SOAP code, but wasn't able to
> find where.

Are you using PHP 4? It's possible we're missing a reference  
somewhere, or that PEAR SOAP is, but with PHP 5 that shouldn't be an  
issue.

-chuck