[dev] Horde_RPC_soap tweaks

[John Morrissey]

On Mon, May 21, 2007 at 01:33:24PM -0400, Chuck Hagenbuch wrote:
> Quoting John Morrissey <jwm at horde.net>:
> > We've made some changes to Horde_RPC_soap locally to support a somewhat
> > substantial (~55-70k SOAP calls/day) Horde application.
> 
> Cool - any chance you can tell us what the app is? :)

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.

> > 1. Adds a restrictCalls parameter, a regex that calls must match to be
> >    allowed.
> 
> 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).

To give you an idea, to create our customer-facing SOAP endpoint, we copied
horde's rpc.php and modified it for SOAP-only use, using a restrictCalls
argument in only that copy of rpc.php. The "internal use" endpoint uses
horde's unmodified rpc.php and the customer-facing endpoint uses the
modified rpc.php.

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. :-)

> > 3. Adds logging of SOAP calls (method, arguments, calling user,
> >    elapsed time, and bytes output) at PEAR_LOG_INFO.
> 
> I'd make the level PEAR_LOG_DEBUG, but otherwise this is good.

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.

john
-- 
John Morrissey          _o            /\         ----  __o
jwm at horde.net        _-< \_          /  \       ----  <  \,
www.horde.net/    __(_)/_(_)________/    \_______(_) /_(_)__