Sexing up the Tycho local store

After many iterations benchmarking the message passing layer of Tycho I have revisited the VR code cleaning it up and making it more robust.

While writing Tycho the VR code was hacked together to provide enough functionality to let clients discover each other to allow us to test the message passing parts of the system. More recently we added the P2P layer to allow Mediators to discover each other over the wide-area.

I have overhauled most of the VR code and only outline one of the changes here.

In previous VR implementations we supported multiple query languages and response markups by using a generic internal format. The drivers for the back end stores (JDBC and in-memory) had code to read these generic queries. This led to a rather convoluted process where the query in SQL would be translated into the generic form and then the JDBC data store driver would convert the query back into SQL and execute it.

The new code checks to see if a query can be used by a back end store directly and skips the intermediate format. This follows the implementation process used for the rest of Tycho ? minimise the number of copies. The cool thing is if you use a back end store which supports SQL you can leverage powerful features of the SQL language in your Tycho registry queries. A simple example using wildcards:

SELECT name FROM clients
WHERE type='producer' AND name LIKE 'cam_control-%';

Embedding HSQLDB will make this very cool as you will be able to use full blown SQL without installing anything (like MySQL).