xmlrpc introspection

[Bryan]

i see a scalability problem with listMethods.  we have a server that
dynamically loads many providers.  each provider registers one or more
services.  each service handles one or more methods.  so a typical method
name would be service.method or for example calculator.add.  when the server
receives calculator.add, it knows to send it to all providers that
registered for calculator service.  now when our server receives a
listMethods request, it has to return all the method names in all providers.
this could be hundreds or even thousands.  it would be nice if it was
standard that there was a listServices request and listMethods took an
optional service parameter.  then you can scale this up.  i noticed that
it's typical to have method names in the format service.method so i'm too
far off with this.  i'm probably going to have to implement it this way, i
just wish it was the "standard" way.

bryan

"poiboy" <bitbucket at safe-mail.net> wrote in message
news:af6b5bdd.0304240434.fd7e6ad at posting.google.com...
> Quick answer: Register 'system.listMethods', 'system.methodSignature',
> and 'system.methodHelp' in your server and make sure they perform as
> stated in the docs (listMethods returns a list of strings, etc.). Yup
> - just do it all by hand.
>
> The output for these methods are typical <methodResponse>s (snippets
> available at http://www.xmlrpc.org/spec) - which *should* be taken
> care of automatically by the XMLRPC server; lists and/or strings
> converted to something like
>
> <?xml version="1.0"?>
> <methodResponse>
>     <params>
>         <param>
>             <value>
>                 <array>
>                     <data>
>
> <value><string>remoteMethodOne</string></value>
>
> <value><string>remoteMethodTwo</string></value>
>
> <value><string>remoteMethodThree</string></value>
>                     </data>
>                 </array>
>             </value>
>         </param>
>     </params>
> </methodResponse>
>
> ..for 'server.listMethods'. In other words, you *shouldn't* have to
> worry about the raw XML. Verify your server's output democratically
> via the debugger link above
> (http://www.dscpl.com.au/xmlrpc-debugger.php - added to my bookmarks,
> mahalo Graham!) or manually by testing 'server.listMethods' at
> http://xmlrpc.usefulinc.com/demo/server.php.
>
> A headstart on introspection can be found at
> http://xmlrpc-c.sourceforge.net/hacks/xmlrpc_registry.py, and there's
> a detailed account of a comprehensive 'system.describeMethods'
> implementation at
http://xmlrpc-epi.sourceforge.net/specs/rfc.system.describeMethods.php
> which I recommend for practical documentation consideration.
>
> Two unsolicited cents worth: Complimentary RPC test cases are
> invaluable (list all methods as links, click to test individually or
> click "test all"). Had to get that off my chest.
>
> Aloha, the poiboy