Honoré David wrote: > It would be more efficient to store lucene index into slide BUT > implement org.apache.lucene.store.Directory via slide API (on the server > side) directly and not over and HTTP connection. > (Anyway the indexer is server side.)
Yes, implementing it directly onto the Slide API is more efficient, but not efficient enough alone I’m afraid. I got a Lucene index for a customer that is over 2GB of size and even if this is split into several Lucene files, many of these files are just to large to handle without some paging I think. Further more a clean WebDAV implementation would be much more flexible and reusable for the Lucene project to, not only Slide. > note: Lucene juste need (Create => Write_only => Close) and (Open => > Random_Read_only => Close). and delete Lucene never "modify" the "file", > but you need not to just implement org.apache.lucene.store.Directory > Interface but also a org.apache.lucene.store.InputStream, > org.apache.lucene.store.OutputStream, ... etc > > I can find some time to work on this if someone think this is something > usefull. Lucenes InputStream and OutputStream requires seek() even if the actual files doesn’t. I have abused the RAMDirectory for a while now and I think that taking the code in that implementation would be a nice start for implementing a DAVDirectory. It already does paging into arrays, so the work would be to save and load these arrays into slide and adjust the maximum allowed size of each “file”. Lucene sees collections of these paged arrays as files, so we would need a filename translation that says that file “lucene.segment” actually is chunked out into a set of small WebDAV resources. > But all of this doesn't help for re-index... : ( Eh... true, but wouldnt it be cool? :-) Mvh Karl Øie --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
