I think that a driver should not be configured at all in a complex way. A driver should be ready for use right away, with no need to locate a configuration file on a filesystem, this is why I'm more or less OK with System.setProperty: I want to embed all the configuration data on a URL, like JDBC does.
That's why xmldb.base.api.Database has the methods "setProperty" and
"getProperty". In the case of the embed mode"driver" we are not configuring the driver, but the client (or to be more precise the server that resides inside the client).
_if_ you want that "A driver should be ready for use right away, with no need to locate a configuration file on a filesystem" _than_ you have to modify the embed client so that it doesn't require a configuration file. AFAIK the embed client *requires* a configuration file so the question is not _if_ but _how_ to pass this configuration file to the client.
I'm still wondering if this is a good thing at all, security and usability wise. I see XMLRPC as a transport, period. New commands and features should be added system wide, not by a casual user, with their XMLRPC based implementation as a side effect.
1) the XMLRPC messages are located on the server (org.apache.xindice.SERVER.rpc.messages), and I hope that not every "casual user" has physical access to the server
2) why shouldn't administrators (and not casual users) be able to replace/specify other XMLRPC messages? Simply because *we* thing that
*they* are not able to handle the security aspect?
Someone proposed the Grep function but noone came up with a solution to integrate it smoothly. Can someone propose a solution? (since this has to do with the configuration, I will not volunteer)
I don't think that this, however, should be an issue for this release.
I don't want to reimplement the configuration (and force every user to change their configuration too) at every release, so I prefer to see where we are going.
I never said that the Grep should be in the release (not even in any release), I just said that be integrating this message into our architecture, we will better see how we can extend Xindice.
How do you know if Xindice is extendable if you have never tried to extend it?
There might be a 1.2 shortly with some additions (metadata and, maybe, security, if we all agree)
Well AFAIK metadata is *already* in the codebase.
-Vladimir
-- Vladimir R. Bossicard Apache Xindice - http://xml.apache.org/xindice
