From: Vadim Gritsenko > Upayavira wrote: > > > Vadim Gritsenko wrote: > > > >> Geoff Howard wrote: > >> > >>> Vadim Gritsenko wrote: > >>> > >>>> Xindice has a Filer abstraction, and there is BTreeFiler > >>>> implementation. It stores binary objects under an > arbitrary binary > >>>> key, and keys are organized into the BTree for fast > >>>> store/retrieval. See test for filer here: > >>>> > >>>> > >>>> > http://cvs.apache.org/viewcvs.cgi/xml-xindice/java/tests/src/o rg/ap >>>> ache/xindice/core/filer/FilerTestBase.java?view=auto >>>> >>>> >>>> Filer uses several RandomAccessFile descriptors to provide >>>> concurrent reads / writes to the file. >>> >>> >>> >>> >>> Does that answer mean you think a XIndice persistent store >>> implementation would be a good fit? As you're involved heavily in >>> both projects, you'd be the best to comment probably... >> >> >> >> >> It would work. Take a look at the linked class, as well as at Filer >> interface. What's your opinion? > > > That's what I think. It would work. The issue in my mind is more to do > with performance. Could it compete with jisp? Do you have any thoughts
> there Vadim? > Well, this I don't know (and I never looked into Jisp source code - so > can't comment on its workings). Do you want to test it? > > What I know is that filer is ~ 100kb of Java source code, so it would be > easier to find / fix bugs, if any. In compiled form it will be even > less. To address Reinhard's concern, it could be packaged into separate > jar, of Jisp size or so. So, if Jisp sticks to GPL, we still would have > several options - from JCS to Xindice Filer. This sounds good to me :-) > PS What's JCS size / performance / etc? *If* it is necessary to switch I think we need some tests ... -- Reinhard
