XML-RPC Introspection

Status

Author

Tarek ZiadÃÂ© (tziade@nuxeo.com)

Problem/Proposal

Implement a XML-RPC Introspection mechanism into Z3.

A few words on XML-RPC introspection: Introspection give to XML-RPC what SOAP already has gathered in WSDL Dictionnaries:

a list of all methods available on the server (i.e. on the given view)
for each method, a short documentation (i.e. the docstring)
for each method, the interface to use it (i.e. the list of method arguments)

That let the client application do API discovering on the target server. The XML Introspection API has been proposed here: http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto-api-introspection.html and has been implemented in Python xmlrpclib module: http://docs.python.org/lib/serverproxy-objects.html

Goals

Write the introspection mech anism in z3
A nice-to-have demo, besides the tests, would be a small desktop program that does api discovery against a zope server, like some exists with docs

Proposed Solution

Adding these API in Zope 3 can be done by implementing a generic view that would publish those methods, based on MethodPublishers? introspection like what we have in zope.app.apidoc.

The standard xml-rpc introspection says that a given RPC server provide the three methods for the whole portal, so a client can actually do:

    >>> import xmlrpclib 
    >>> server = xmlrpclib.Server("http://some.site/rpcview") 
    >>> for method in server.system.listMethods():
    >>>     print method
    >>>     print server.system.methodHelp(method)
    >>>     print server.system.methodSignature(method)

possible interface (based on the common api standard):

    class IXMLRPCIntrospector(Interface):
       """IXMLRPCIntrospector """
       def listMethods():
           """ lists all xmlrpc methods implemented by the object """       def methodHelp(method_name):
           """ returns the docstring of given method """
       def methodSignature(method_name):
           """ returns the signature of given method
           ie the list of all arguments
           """

Risks:

watch other point of interest in the meantime, that can be implemented in the future, like
- Boxcarring: add a multicall() method so clients can send multiple request at once:
  - http://www.xmlrpc.com/discuss/msgReader$1208

comments:

Collision risk --efge, 2005/10/03 16:38 EST reply
If I understand, this will be implemented as xmlrpc views registered for all objects. Note that this poses the risk of name collisions for the views.

You should also mention associated security problems.

Re: Collision risk --srichter, 2005/10/03 17:23 EST reply

If I understand, this will be implemented as xmlrpc views registered for all objects. Note that this poses the risk of name collisions for the views.

I disagree. If it is registered for Interface, you can always override this registration. by registering new/empty views for more specific interfaces.

Of course another option would be to provide a new XML-RPC specific directive that let's you quickly register the introspection methods for a given interface. But I would find this less desirable.

You should also mention associated security problems.

Of course, only methods you have actually access to should be returned.

Re: Collision risk --efge, 2005/10/03 17:30 EST reply

you can always override this registration

But then XMLRPC code that expected some other behaviour from that view would fail.

For the record: I don't think name collision is a big risk at all, I just thought it should be mentioned. Same for security.