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]
