On Tue, Apr 5, 2011 at 11:23 AM, Michael McCandless <luc...@mikemccandless.com> wrote: > Forgive my ignorance, but: are there any technical reasons for spatial > work to be "in core"?
There is no reason it needs to be in core. As is, it is a maven build that depends on -SNAPSHOT and everything works great. > > Or can all the spatial algos be "safely" (ie, won't lose much > performance, if any) built "on top" of Lucene's (Solr's) APIs? Do we > need to open up new APIs (in which case being part of one code base, > released together, is a strong advantage)? > Not that i can think of -- it is right now using features that will get better when new things are added to lucene (for example the docvalues branch) but i think that is true of any project built on top of lucene. My push to have a Numeric field that both solr and lucene use was motivated by this project. Again, not a unique problem to spatial. Also, i recently changed some package protected constants in solr to protected -- so that an external library could make complex solr FieldTypes. > For example, incremental field updates is a long needed and often > requested feature in Lucene, but this really couldn't be > easily/efficiently build "on top" -- it requires access to lots of > inside details that are tracked during indexing. > Nothing like that in spatial contrib. The closest I can think of (and this is a long shot) I can see writing a spatial codec that writes values to an rtree. But even this should be able to work within published (or SNAPSHOT) apis. More importantly, the people who would work on the core lucene problems vs the people who would work on the majority of spatial problems are pretty different. It would be nice if spatial contributions could not possibly break the lucene build. ryan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
