hey On Jun 11, 2009, at 09:52, Navin Surtani wrote: hum no, it's done, that's the work you have done basically. Something can likely be done to abstract some of the query engine but I'm not sure how much. This needs ot be experimented. The idea is to get the infinispan data indexed in Lucene and stored... well in Lucene as well. HSearch would be the query engine of Infinispan. One question was whether or not create a JPA-QL / JPA2 Criteria API layer on top of Lucene queries at least for non join or simple join queries. It's an orthogonal project though. The idea was to index the local data (node-wise). We can call each node to get a global result (we will need to adjust Hibernate Search in this area as we only do local IndexReaders today but AFAIK that's doable). The hard problem to crack is how Hibernate Search will deduplicate the results. Infinispan does partly duplicate data, hence the query will return the same data several times. Not much that will impact you. We have a new backend that is JGroups based. sow e have lucene, JMs and JGroups now. not sure what's the fundamental difference so OK :) yes One thing we are working on is massive indexing. Sanne can talk more about that but I frankly don't think that will impact infinispan in the near term. The rest was under the hood optimizations and some cool new higher level features. nope but I think that would be a good time to: - think about sharing some of the search infrastructure (FullTextQueryImpl has some reusable stuffs likely) - rethink the query API after hearing feedback from users. (I was not 100% happy with the JBCS API)