That's true, using the full class name does allow adding additional classes. However, I think a configuration file allows for an added level of indirection that would be useful for some applications. For example, imagine that you have code accessing Xindice thru XMLRPC in a 'production' and a 'development' environment. You want this code to be identical between the two environments (that is, the xmlrpc method name invoked is identical). But in the development env, you want some editorial controls output as well. In this scenario, you'd want a configuration file for the Xindice XMLRPC server to list the 'editing' class in development and the 'display' class in production.
On the other hand, in the scenario I describe, the application invoking the xmlrpc method could also read a config file to determine the name of the class to invoke. This would also allow for identical code to run in development and production. However, I think that as a Xindice user/administrator, it would be nice if I could do this type of manipulation from a Xindice configuration file rather than an application configuration file. I suspect there are other times when an XMLRPC configuration file would be useful... This was simply the first one that came to my mind. dave -----Original Message----- From: Vladimir R. Bossicard [mailto:[EMAIL PROTECTED] Sent: Thursday, December 05, 2002 9:37 AM To: [EMAIL PROTECTED] Subject: RE: xml-rpc messages > One possible solution would be for the RPCMessageInterface class to read a > configuration file on startup which would map RPC method names to class > names that service that method. I proposed to map the method names with the class full names. You can than define your additional classes wherever you want. The name of the method is simply 'my.full.package.path.myClass' -Vladimir ===== Vladimir R. Bossicard Apache Xindice - http://xml.apache.org/xindice __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
