At 02:41 PM 10/26/99 -0400, you wrote:
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.
Right. This allows a very open-ended use of XML-RPC from DTML.
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.
Well, you could acquire the server URL. This would improve flexibility. Another important benefit of an XML-RPC Method as opposed to a Server is that it limits what you can do in DTML. This allows some folks to control the hairy stuff (like XML-RPC settings) while others just use it via DTML. The Zopish thing to do (not that I can speak to whether this is always right or not) is to wrap access to external resources like the filesystem, and databases. Probably Chris or Jim could comment on the security implications of this better that I can.
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.
Perhaps. If for example, the xml-rpc server requires basic authentication or ssl to access, then this two-object approach might make more sense. If a server is just a URL, then I agree that having an object to represent a URL is overkill.
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.
My thoughts are that when you define an XML-RPC Method you have some idea of what you are dealing with. You could then set a sensible caching parameters. For example, cache for N hours. Of course caching is more complex, for example if the method takes arguments you might not want to cache results, or might want to cache them based on the arguments. For example, the UserLand state names method is one that should be cached indefinitely but by method argument. My guess is that a simple 'cache for N hours' setting on methods would provide much of the needed functionality with very little complexity. -Amos