Random thoughts - JZKit3

After a morning trying to fit the SQI square peg into the SRW round hole, I'm having some thoughts about re-organising the search plugins and the aggregator service in JZKit3. It seems with the way the world is today, with alerters and users creating their own data feeds (The horrible, if cool pipes demo, which could be so much more, if only it worked). The problem we have with JZKit right now is that some of the plugins require oodles of configuration (JDBC/Relational Database Plugin) wheras others require nothing more than a url (Z3950 URL, SRW/SRU, etc). To create a simple search portal app thats easily installed, users don't want to have the grief of learning about relational database plugin config. We thought we cracked that nut in jzkit2 by having the plugins register their own config mechanisms, but the config woes persist. So, how about, after thinking harder about how we can work with SQI, we split the plugins into two classes, those that are URL configurable and those that aren't. The ones that arent need to be exposed as an SRW/SRU/Z3950 service in their own right, and are then aggregated by the simpler plugins. This *vastly* simplifies the config (Still have all the query rewrite stuff to deal with, but at least it cuts out the big problem, which is database config). This also fits with rewriting the jdbc plugin to use hibernate map based objects instead of our home-grown persistence layer. Sounds like a good direction for jzkit3.