You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2004/02/20 16:11:25 UTC
Xindice filer, Re: Jisp 3.0 moved to GPL licence
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.
Vadim
Re: Xindice filer, Re: Jisp 3.0 moved to GPL licence
Posted by Geoff Howard <co...@leverageweb.com>.
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
Posted by Torsten Curdt <tc...@vafer.org>.
>>> 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
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Posted by Upayavira <uv...@upaya.co.uk>.
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
Posted by Reinhard Poetz <re...@apache.org>.
From: Vadim Gritsenko [mailto:vadim@reverycodes.com]
> 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
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Posted by Geoff Howard <co...@leverageweb.com>.
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