[Zope-dev] XMLRPCMethod product

[Amos Latteier]

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