But I think that some configuration along these lines would be extremely
simple to implement and provide the Xindice administrator complete control
over what XMLRPC methods are exposed and even allow him/her to add his/her
own methods without mucking inside the core of Xindice.
Gianugo things it's not a good idea. You think it's a good idea.
Who's right?
Probably both and no one of us. I'd say that it might be possible to use an overridable default configuration, loaded via the ClassLoader so that it can be embedded in the Jar. If you really want to muck with it, at least you have to know what you're doing. But, outside of a well-tought container, there is no reliable way to deal with classloaders.
Ok so now every "driver" (or client) potentially needs its own configuration file. Moreover, some configuration file are only meant to be on the server (xmlrpc.xml) and/or on the client (system.xml for the embed driver). We don't have to forget the security configuration file which will be either on the server (xmlrpc) and on the client (embed mode, but NOT xmlrpc mode).
Did I heared someone talking about a "centralized" configuration?
Don't look at me. I'd Avalonize everything right away, and you were the one complaining about a configuration file being crippled with stuff you don't need. :-)
Ciao,
-- Gianugo
