Re: Xindice filer, Re: Jisp 3.0 moved to GPL licence
Torsten Curdt wrote: 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? Hm... A full blown XIndice because we want the persitant store? Do you really think that's a good idea? Actually, haven't we considered doing this anyway? I have a dim memory of us wanting to put an xml fragment store in the core for some performance miracle... I'd rather see this part ripped out of XIndice and put into Avalon and share it that way instead of using XIndice. Sounds like Vadim already suggested a separate jar... Geoff
Re: Xindice filer, Re: Jisp 3.0 moved to GPL licence
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? Hm... A full blown XIndice because we want the persitant store? Do you really think that's a good idea? I'd rather see this part ripped out of XIndice and put into Avalon and share it that way instead of using XIndice. *shrug* -- Torsten
RE: Xindice filer, Re: Jisp 3.0 moved to GPL licence
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
Re: Xindice filer, Re: Jisp 3.0 moved to GPL licence
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/org/apache/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. PS What's JCS size / performance / etc? Vadim
RE: Xindice filer, Re: Jisp 3.0 moved to GPL licence
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] > Geoff Howard wrote: > > > Vadim Gritsenko wrote: > > > >> Upayavira wrote: > >> > >>> Antonio Gallardo wrote: > >>> > Maybe this is a crazy idea but: Is posible to replace jisp with > Apache Xindice? Mainly because I have concerns for another ugly > move (as jisp > did) if we choose a solution from a 3rd party again. If > we use Apache > Xindice I think this cannot happen again. > > >>> Could do. How efficient is XIndice? It would need to be pretty > >>> efficient on binary data too, as that is our primary use case. > >> > >> > >> > >> 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/org/apac > >> he/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? Using XMLDB would mean another ~500KB more in Cocoon core ... :-( -- Reinhard
Re: Xindice filer, Re: Jisp 3.0 moved to GPL licence
Vadim Gritsenko wrote: Geoff Howard wrote: Vadim Gritsenko wrote: Upayavira wrote: Antonio Gallardo wrote: Maybe this is a crazy idea but: Is posible to replace jisp with Apache Xindice? Mainly because I have concerns for another ugly move (as jisp did) if we choose a solution from a 3rd party again. If we use Apache Xindice I think this cannot happen again. Could do. How efficient is XIndice? It would need to be pretty efficient on binary data too, as that is our primary use case. 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/org/apache/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? Upayavira
Re: Xindice filer, Re: Jisp 3.0 moved to GPL licence
Geoff Howard wrote: Vadim Gritsenko wrote: Upayavira wrote: Antonio Gallardo wrote: Maybe this is a crazy idea but: Is posible to replace jisp with Apache Xindice? Mainly because I have concerns for another ugly move (as jisp did) if we choose a solution from a 3rd party again. If we use Apache Xindice I think this cannot happen again. Could do. How efficient is XIndice? It would need to be pretty efficient on binary data too, as that is our primary use case. 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/org/apache/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? Vadim
Re: Xindice filer, Re: Jisp 3.0 moved to GPL licence
Vadim Gritsenko wrote: Upayavira wrote: Antonio Gallardo wrote: Maybe this is a crazy idea but: Is posible to replace jisp with Apache Xindice? Mainly because I have concerns for another ugly move (as jisp did) if we choose a solution from a 3rd party again. If we use Apache Xindice I think this cannot happen again. Could do. How efficient is XIndice? It would need to be pretty efficient on binary data too, as that is our primary use case. 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/org/apache/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... Geoff
