Vladimir had started seriously documenting the end-user setup experience I believe. This is probably necessary (servlet stuff in particular) for this release, sothat people can actually install it :).
Since I was (indirectly) asked for my opinion, there it is:
I proposed a solution to end up the mess with the configuration of the embed driver but the feedback I received doesn't IMO address the problem. or maybe everyone thinks it's fine to use System.setProperty to configure a driver.
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.
I'm still interested to see how other external XMLRPC commands can be
handled by the xmlrpc driver.
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.
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'm sure that, once we have a release in place and we are free to move to new idea, APIs and maybe codebases, all these problems will be addressed in a much smarter way. So my proposal is to "code freeze" ASAP (we are already in a sort of code freeze anyhow) and start the release process. I see 1.1 out of the door soon with the current codebase. There might be a 1.2 shortly with some additions (metadata and, maybe, security, if we all agree) but I'd start to think about new solutions for Xindice 2.0.
What do you think?
Ciao,
-- Gianugo Rabellino
