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