[Zope-dev] XMLRPCMethod product

[Jay, Dylan]

> -----Original Message-----
> From: Andrew M. Kuchling [mailto:akuchlin@mems-exchange.org]
> Sent: Wednesday, October 27, 1999 04:41
> To: zope-dev@zope.org
> Subject: [Zope-dev] XMLRPCMethod product
> 
> 
> In Amos's XML-RPC HOWTO, he writes:
> 
>    It would be an interesting project (hint, hint) to write an XML-RPC
>    Method Zope Product that was smart about caching, etcetera. This
>    would make XML-RPC available from DTML in a safe form.
> 
> I can take hints, and have a need for easier access to XML-RPC.  So,
> what should an XMLRPCMethod look like?  
> 
> One idea is that it has a single property, the URL for an XML-RPC
> server.  You would set this to http://othersite/zope/ or whatever.
> Assuming your method was given an ID of 'rpcserv', you could then
> write DTML like:
> 
> <!--Use the standard_html_header of another Zope site (!) -->
> <dtml-var "rpcserv.standard_html_header()">  
> 
> <dtml-in "rpcserv.listUsers()">
>   ...
> </dtml-in>
> 
> This would be better named XMLRPCServer than *Method.
> 
> Alternatively, by analogy with ExternalMethods, an XML-RPC Method
> could pin things down to a single method; you might create one for
> listUsers() on a given server, another for standard_html_header() on
> that site, etc.  I don't like this, because it means you may have lots
> of different method objects, and when a server moves, a lot of
> updating is required.  Too inflexible for my taste.

I think your former suggestion is excellent. With a XMLRPCServer you can use
a DTML method or python method to wrap a particular function if it was used
a lot anyway. 

 
> You could make updating server URLs easier by doing something similar
> to DAs and SQLMethods, having XMLRPCMethods use a given XMLRPCServer
> object, just as SQLMethods use a given database object.  This strikes
> me as over-engineering the problem, though, resulting in two new
> object types, and is still rather inflexible.
> 
> Caching is an interesting problem.  Who can know whether a given
> XML-RPC method is returning relatively static data that's constant for
> several hours, or transient data that changes a lot?  Only the XML-RPC
> server, and maybe the caller, can know this.  I don't think a solution
> is possible until XML-RPC supports some way to signal whether a
> method's results are cacheable or not, so I don't think caching is
> possible at this point in time.

I think a better way to achieve caching is as a seperate entity altogeather.
This was suggested awhile back in a big discussion about caching. What is
needed is an object that wraps the method be it a DTML method, external
XMLRPC method whatever. This will act exactly as the orginal method but will
do cache management. You can set your own caching scheme (refresh once a
week or whatever). The only problem with this is that the cache needs to
know the entire context that makes up a call so that if the context was
presented again then it could return the cached version. This is bit hard
with aquisition.