You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2004/02/20 11:52:46 UTC
Jisp 3.0 moved to GPL licence
> Am 14:01 10.02.2004 -0500 schrieb Steve Krulewitz:
> >Does anyone know what happened to the jisp website? The old URL
> >http://www.coyotegulch.com/jisp/index.html sends you to an
> invalid link.
>
> It's back up now: http://www.coyotegulch.com/jisp/
> I never went there before it went down, but it now has a
> version 3.0.0. That version isn't under the old license
> anymore but GPLed (or commercial
> for 2500$).
> Old versions I can't find there..
>
> gunnar
>
> ps: sorry if you get this mail twice, steve. small mistake by me.
>
> --
> G. Brand - interface:projects GmbH
As our store depends on Jisp - what does this mean for us? IMO we have
to look for a replacement. Any ideas/hints?
--
Reinhard
Re: Jisp 3.0 moved to GPL licence
Posted by Upayavira <uv...@upaya.co.uk>.
Joerg Heinicke wrote:
> On 20.02.2004 11:52, Reinhard Poetz wrote:
>
>>> I never went there before it went down, but it now has a version
>>> 3.0.0. That version isn't under the old license anymore but GPLed
>>> (or commercial for 2500$).
>>> Old versions I can't find there..
>>
>>
>>
>> As our store depends on Jisp - what does this mean for us? IMO we have
>> to look for a replacement. Any ideas/hints?
>
>
> On the thread about the announcement of Momento there was mentioned a
> "journaling file data structure" [1], Stefano asked if it is a
> replacment for JISP [2] and in Alan's opinion it might be possible [3].
>
> As I don't know the requirements I can not evaluate it though.
I did think of this. But, it seems that Momento is all about XML, whilst
JISP is a generic 'binary' store. Whilst we do cache XML, we also cache
serialized content, i.e. binary data, and I would say that that is our
primary use case. So, Momento might be able to do that, but it doesn't
seem to be the main problem it is trying to sove.
Regards, Upayavira
>
> [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107700015102265&w=4
> [2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107711295731173&w=4
> [3] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107712768202660&w=4
> [4] complete thread:
> http://marc.theaimsgroup.com/?t=107695997200006&r=1&w=4
>
Re: Jisp 3.0 moved to GPL licence
Posted by Joerg Heinicke <jo...@gmx.de>.
On 20.02.2004 11:52, Reinhard Poetz wrote:
>>I never went there before it went down, but it now has a
>>version 3.0.0. That version isn't under the old license
>>anymore but GPLed (or commercial
>>for 2500$).
>>Old versions I can't find there..
>
>
> As our store depends on Jisp - what does this mean for us? IMO we have
> to look for a replacement. Any ideas/hints?
On the thread about the announcement of Momento there was mentioned a
"journaling file data structure" [1], Stefano asked if it is a
replacment for JISP [2] and in Alan's opinion it might be possible [3].
As I don't know the requirements I can not evaluate it though.
Joerg
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107700015102265&w=4
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107711295731173&w=4
[3] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107712768202660&w=4
[4] complete thread: http://marc.theaimsgroup.com/?t=107695997200006&r=1&w=4
Re: Jisp 3.0 moved to GPL licence
Posted by Steven Noels <st...@outerthought.org>.
On 20 Feb 2004, at 15:44, Stefano Mazzocchi wrote:
> We have the right to fork, keep this in mind.
I wouldn't advocate this as a matter of practice. But your point is
perfectly valid.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Jisp 3.0 moved to GPL licence
Posted by Stefano Mazzocchi <st...@apache.org>.
Reinhard Poetz wrote:
>>Am 14:01 10.02.2004 -0500 schrieb Steve Krulewitz:
>>
>>>Does anyone know what happened to the jisp website? The old URL
>>>http://www.coyotegulch.com/jisp/index.html sends you to an
>>
>>invalid link.
>>
>>It's back up now: http://www.coyotegulch.com/jisp/
>>I never went there before it went down, but it now has a
>>version 3.0.0. That version isn't under the old license
>>anymore but GPLed (or commercial
>>for 2500$).
>>Old versions I can't find there..
>>
>>gunnar
>>
>>ps: sorry if you get this mail twice, steve. small mistake by me.
>>
>>--
>>G. Brand - interface:projects GmbH
>
>
>
> As our store depends on Jisp - what does this mean for us? IMO we have
> to look for a replacement. Any ideas/hints?
We have the right to fork, keep this in mind.
--
Stefano.
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
Xindice filer, Re: Jisp 3.0 moved to GPL licence
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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: Jisp 3.0 moved to GPL licence
Posted by Stefano Mazzocchi <st...@apache.org>.
Upayavira wrote:
> Antonio Gallardo wrote:
>
>> Reinhard Poetz dijo:
>>
>>
>>>> Am 14:01 10.02.2004 -0500 schrieb Steve Krulewitz:
>>>>
>>>>
>>>>> Does anyone know what happened to the jisp website? The old URL
>>>>> http://www.coyotegulch.com/jisp/index.html sends you to an
>>>>>
>>>>
>>>> invalid link.
>>>>
>>>> It's back up now: http://www.coyotegulch.com/jisp/
>>>> I never went there before it went down, but it now has a
>>>> version 3.0.0. That version isn't under the old license
>>>> anymore but GPLed (or commercial
>>>> for 2500$).
>>>> Old versions I can't find there..
>>>>
>>>> gunnar
>>>>
>>>> ps: sorry if you get this mail twice, steve. small mistake by me.
>>>>
>>>> --
>>>> G. Brand - interface:projects GmbH
>>>>
>>>
>>> As our store depends on Jisp - what does this mean for us? IMO we have
>>> to look for a replacement. Any ideas/hints?
>>>
>>
>> AFAIK, we must move away from jisp. That was an ugly move! :-(
>>
>> 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.
>
> With the new embedded mode driver for XIndice, it wouldn't be that hard
> to implement, so long as it is efficient enough.
I personally think it's a very bad idea. XIndice is not designed for
these things. Carsten's suggestion seems *a lot* better!
--
Stefano.
Re: Jisp 3.0 moved to GPL licence
Posted by Upayavira <uv...@upaya.co.uk>.
Antonio Gallardo wrote:
>Reinhard Poetz dijo:
>
>
>>>Am 14:01 10.02.2004 -0500 schrieb Steve Krulewitz:
>>>
>>>
>>>>Does anyone know what happened to the jisp website? The old URL
>>>>http://www.coyotegulch.com/jisp/index.html sends you to an
>>>>
>>>>
>>>invalid link.
>>>
>>>It's back up now: http://www.coyotegulch.com/jisp/
>>>I never went there before it went down, but it now has a
>>>version 3.0.0. That version isn't under the old license
>>>anymore but GPLed (or commercial
>>>for 2500$).
>>>Old versions I can't find there..
>>>
>>>gunnar
>>>
>>>ps: sorry if you get this mail twice, steve. small mistake by me.
>>>
>>>--
>>>G. Brand - interface:projects GmbH
>>>
>>>
>>As our store depends on Jisp - what does this mean for us? IMO we have
>>to look for a replacement. Any ideas/hints?
>>
>>
>AFAIK, we must move away from jisp. That was an ugly move! :-(
>
>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.
With the new embedded mode driver for XIndice, it wouldn't be that hard
to implement, so long as it is efficient enough.
Regards, Upayavira
Re: Jisp 3.0 moved to GPL licence
Posted by Antonio Gallardo <ag...@agssa.net>.
Scott Robert Ladd dijo:
>> On 20.02.2004 12:25, Antonio Gallardo wrote:
>>> AFAIK, we must move away from jisp. That was an ugly move! :-(
>
> I'm willing to work with Apache on this issue, so how am I being ugly?
Hi:
Sorry, Scott It was not addressed to you. I am glad to hear that. :-D
Best Regards,
Antonio Gallardo
Re: Jisp 3.0 moved to GPL licence
Posted by Scott Robert Ladd <co...@coyotegulch.com>.
> On 20.02.2004 12:25, Antonio Gallardo wrote:
>> AFAIK, we must move away from jisp. That was an ugly move! :-(
I intended no ugliness; I never even considered that Apache would be
offended by my change in license.
When I used libpng, I had people complaining I wasn't using GPL; when I
use the GPL, people complain that I should use something else. I'm sure
you can understand this, given the current controversy over changes in
Apache's license.
I'm willing to work with Apache on this issue, so how am I being ugly?
..Scott
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing
Re: Jisp 3.0 moved to GPL licence
Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke dijo:
> On 20.02.2004 12:25, Antonio Gallardo wrote:
>
>> AFAIK, we must move away from jisp. That was an ugly move! :-(
>
> IMO you can not convict somebody just because he chose a license that
> does not match your requirements. He probably did not do that to make us
> angry. Maybe you chose only a wrong word (as the English language is not
> the natural language of most of us) but 'ugly' is a really hard word in
> this context I think.
Sorry, for the word. I know everybody is free to choose the License that
meet the best for him. I just tried to point this was a not good move from
us. I don't really know people behind jisp and not tried to flame them. I
saw this just from my own (Cocoon) perspective. Please forgive me if it
can be interpreted in other way. English is not my natural language.
Please don't take the words in a wrong sense.
Best Regards,
Antonio Gallardo
Re: Jisp 3.0 moved to GPL licence
Posted by Joerg Heinicke <jo...@gmx.de>.
On 20.02.2004 12:25, Antonio Gallardo wrote:
> AFAIK, we must move away from jisp. That was an ugly move! :-(
IMO you can not convict somebody just because he chose a license that
does not match your requirements. He probably did not do that to make us
angry. Maybe you chose only a wrong word (as the English language is not
the natural language of most of us) but 'ugly' is a really hard word in
this context I think.
Joerg
Re: Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]
Posted by Alan <al...@engrm.com>.
* Geoff Howard <co...@leverageweb.com> [2004-02-24 00:31]:
> Upayavira wrote:
>
> >[changing subject...]
> >
> >Reinhard Poetz wrote:
> >
> >>From: Alan
> >>
> >>>* Geoff Howard <co...@leverageweb.com> [2004-02-22 18:47]:
> >>>
> >>>
> >>>>Alan wrote:
> >>>>
> >>>>
> >>>>>* Upayavira <uv...@upaya.co.uk> [2004-02-22 07:58]:
> >>>>>
> >>>>>
> >>>>>>I tend to think that Momento isn't suited to this need.
> >>>>>
> >>>>>>However, as an XML data repository, it seems very interesting.
> >>>>>>
> >>>>>
> >>>>>I've got a better idea of how Jisp is used in Cocoon from reading
> >>>>> all the discussion after my post.
> >>>>>
> >>>>> I suggested Momento because someone suggested Xindice which led
> >>>>> me to believe Jisp handled an XML persistence task.
> >>>>>
> >>>>> Might not be the best bet, no.
> >>>>>
> >>>>
> >>>>Still, I think finding a way to use momento to reduce
> >>>
> >>>memory overhead
> >>>
> >>>>in
> >>>>working with large xml datasets has great potential. No one really
> >>>>knows how great, but a demo/sample using it would be a
> >>>
> >>>start... (hint
> >>>
> >>>>hint :) )
> >>>>
> >>>
> >>>Working on it. As noted, I have JAXP implemented and SAX interface
> >>> to XUpdate. I have APIs. I am going to start working on services
> >>> next.
> >>
>
> JAXP... see below....
>
> >>> A Cocoon generator that takes a Momento data source and an XSLT
> >>> transform would be a start.
> >>>
> >>> I'm not sure how to get information into Momento via Cocoon. I'm
> >>> thinking about some sort of Woody binding, but that goes beyond
> >>> my current understanding of Cocoon.
> >>>
> >>
> >>speaking without following this thread closly: What about
> >>implementing a Momento source?
> >
>
> I starting to wonder if I'm being dense... wouldn't the easiest first
> test integratin be to use Memento as the JAXP xslt processor to reduce
> memory overhead on transformations of large data sets? Maybe I've
> misunderstood where/what momento is as a project? The jaxp processor
> is declared in cocoon.xconf (see instructions for switching to saxon
> for example).
I created a blog entry today:
Momento Inline
2004/02/23 12:26:54
There is a mode of operation for Momento that I've not considered
at length. Inline operation with XSLT. That is, operation where
Momento is not a data source, rather it is a transient document
object model.
This applies when performing a transform against a document that
may be too large to fit in system memory. A common use case is XML
generated from an SQL query. The SQL result set can be streamed as
a series of SAX events that clogs memory as the XSLT engine tries
to build a document representing a large data set.
There is nothing preventing Momento from building a document,
organized and clustered at the get go. More interesting would be
for Momento to build the document in memory, writing it to disk
only when memory runs out.
Currently, Momento writes its pages as it fills them. Momento might
delay a page write until a page fills, when it makes sense to do
so, but it pretty much writes the pages to disk as it writes nodes
and strings to the pages. It pools pages in memory using weak
references. When no one is writing to or reading from a page, the
weak reference will be the only reference, thus it is eligible for
garbage collection. Momento would have to intercept the garbage
collector's desire to release the page, and write it out before the
memory is released.
This means I need to develop a deeper understanding of weak
references in Java. If there is no way to hook collectection before
the fact, I'd have to rethink the paging engine so that it would
explicitly release pages as part of a MRU cache.
A hybrid of this could be used to maintain XSLT output as part of a
cache system. Momento would build the result of an XSLT transform
organized and clustered, writing it to disk when memory is tight. A
cache could use this Momento document as a source of SAX events or
as a W3 DOM document, discarding it when the upstream dependencies
change.
So, no Geoff, I'm only getting around to thinking of Momento as an
transient document object model. I'd designed it as a persistence
engine, so I'd considered Momento to be a source of data, a
place where data lives.
(I'll get back to everyone else soon. Great stuff everyone. Thank
you so very much!)
--
Alan / alan@engrm.com / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com
Re: Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]
Posted by Geoff Howard <co...@leverageweb.com>.
Upayavira wrote:
> [changing subject...]
>
> Reinhard Poetz wrote:
>
>> From: Alan
>>
>>> * Geoff Howard <co...@leverageweb.com> [2004-02-22 18:47]:
>>>
>>>
>>>> Alan wrote:
>>>>
>>>>
>>>>> * Upayavira <uv...@upaya.co.uk> [2004-02-22 07:58]:
>>>>>
>>>>>
>>>>>> I tend to think that Momento isn't suited to this need.
>>>>>
>>>>>> However, as an XML data repository, it seems very interesting.
>>>>>>
>>>>>
>>>>> I've got a better idea of how Jisp is used in Cocoon from reading
>>>>> all the discussion after my post.
>>>>>
>>>>> I suggested Momento because someone suggested Xindice which led
>>>>> me to believe Jisp handled an XML persistence task.
>>>>>
>>>>> Might not be the best bet, no.
>>>>>
>>>>
>>>> Still, I think finding a way to use momento to reduce
>>>
>>> memory overhead
>>>
>>>> in
>>>> working with large xml datasets has great potential. No one really
>>>> knows how great, but a demo/sample using it would be a
>>>
>>> start... (hint
>>>
>>>> hint :) )
>>>>
>>>
>>> Working on it. As noted, I have JAXP implemented and SAX interface
>>> to XUpdate. I have APIs. I am going to start working on services
>>> next.
>>
JAXP... see below....
>>> A Cocoon generator that takes a Momento data source and an XSLT
>>> transform would be a start.
>>>
>>> I'm not sure how to get information into Momento via Cocoon. I'm
>>> thinking about some sort of Woody binding, but that goes beyond
>>> my current understanding of Cocoon.
>>>
>>
>> speaking without following this thread closly: What about
>> implementing a Momento source?
>
I starting to wonder if I'm being dense... wouldn't the easiest first
test integratin be to use Memento as the JAXP xslt processor to reduce
memory overhead on transformations of large data sets? Maybe I've
misunderstood where/what momento is as a project? The jaxp processor
is declared in cocoon.xconf (see instructions for switching to saxon
for example).
> Yup. Alan, take a look at the XMLDBSource and XMLDBSourceFactory. I
> think you'll find them reasonably similar to what you might want to do
> (in src/blocks/xmldb/java/org/apache/cocoon/components/source/impl)
>
> If you implemented a MomentoSource, and made it implement
> ModifiableSource, then you would be able to read/write from within
> Cocoon. With this, you would be able to use Woody's binding
> functionality to bind forms directly to Momento data.
>
> You could also do something like the XMLDBTransformer to allow updates
> (src/blocks/xmldb/java/org/apache/cocoon/transformation/XMLDBTransformer.java).
>
>
> [NB. with an XML:DB interface to Momento, you wouldn't need to do
> anything to interface to Cocoon].
These are also good ideas for the write aspect, but I see benefit in the
read aspect if I understood correctly.
Geoff
Re: Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Alan wrote:
> * Daniel Fagerstrom <da...@nada.kth.se> [2004-02-23 15:21]:
<snip/>
>>XSLT
>>====
>
>
>>A MomentoSource would also give a good way to use Momento together with
>>XSLT and XQuery in Cocoon. Here we need to extend the ordinary use of
>>sources somewhat, let me explain:
>
>
>>The Source interface provides a getInputStream method, in Cocoon some
>>Sources implements org.apache.excalibur.xml.sax.XMLizable that provides
>>a toSAX method as well. SAX or Streams are probably not the most
>>efficient way to communicate with an XML db, so to make the pseudo
>>protocol idea usable together with Momento, we should provide a way to
>>get a DOM structure from a pseudo protocol. This could be done by
>>introducing a new interface:
>
>
>>interface DOMizable {
>> org.w3c.domNode getNode();
>>}
>
>
> Momento, with Cocoon in mind, lends itself to streaming.
>
> Momento would readily support a read-only W3 DOM, but a read write
> W3 DOM is quite ugly.
>
> W3 DOM lets you to create inconsistant documents, with is not in
> keeping with the C in ACID. (Examples if you want them.) There
> is no way to specify the start and end of an atomic transcation
> through the DOM API.
>
> Momento uses XUpdate since one can specify a set of modifications,
> and Momento can process those modifications as an atomic
> transcation. XUpdate expresses all document modifications, and
> does so declaratively. Momento can then make logic of you
> intentions.
>
> In a pipeline, XML input can be transformed into XUpdate
> statement. I suppose one could an XUpdate using JXTemplate from
> Flow as well.
>
> XUpdate is really the method of choice for updating Momento.
> Both XUpdate and SAX input are a good way to get data into
> Momento.
>
> I don't know if you and I talking about the same thing here, but
> the sight of org.w3c.domNode leaves me cold. It is a nice
> in-memory interface, but a poor interface for persistence.
>
> If W3 DOM were the way to modify a Momento document, the
> application developer would have to be prepared to catch all
> kinda hel.., er, exceptions, since there are a bunch of stupid
> things that Momento won't allow.
I only talked about read only access of DOM documents from XSLT, don't
worry ;)
>
>
>>or something similar. If the MomentoSource implements DOMizable, we have
>>direct access to nodes in the XML db.
>
>
>>Now we are prepared to connect Momento to XSLT. In Cocoon we can use
>>Saxon through the org.apache.cocoon.transformation.TraxTransformer, you
>>just need to change cocoon.xconf a little bit to use Saxon instead of
>>Xalan. There is also a TraxGenerator in the scratchpad that could be
>>used with some small modifications.
>
>
> Momento connects to XSLT using a Saxon NodeInfo interface. It could
> connect to Xalan just as easily (through read-only W3 DOM?).
Yes, that the idea. It can connect to Saxon through read only DOM as
well, don't know if there are any drawbacks with this though.
>>I would guess that Momento mainly would be accessed through the document
>>function in XSLT and XQuery. Saxon use JAXP 1.1 as external API to the
>>transformerand the URLs in the document functions are resolved by using
>>an implementation of javax.xml.transform.URIResolver that is provided by
>>the TraxTransformer.
>
>
> The above is somewhat confusing for me. Momento does support the
> JAXP API. XUpdate is implemented as a SAX filter. It seems like
> Momento would work nicely in as a source, sink, or filter for
> SAX events.
>
> I've imagined that a pipeline would start with a Momento
> document and an XSLT trasform or XQuery query.
>
> Something along these lines:
>
> <map:match pattern="index.html">
> <map:generate type="momento" src="momento.mx"
> xslt="index-document.xslt"/>
> <map:transform type="xslt" src="document-to-web.xslt"/>
> <map:serialize type="html"/>
> </map:match>
>
> (It is easier for me to express myself as a Cocoon user.)
I rather propose:
<map:match pattern="index.html">
<map:generate type="xslt" src="momento:mydocument.mx"
xslt="index-document.xslt"/>
<map:transform type="xslt" src="document-to-web.xslt"/>
<map:serialize type="html"/>
</map:match>
The idea is that the xslt generator can be used with any source. For
this to be efficient with Momento we must organize so that the XSLT
processor can access momento as a read-only DOM. This will not happen
today in Cocoon. So what I describe is how to extend the involved
mechanisms in Cocoon so that Momento get DOM as input.
This is done by creating a new interface, let us call it
ReadOnlyDOMizable to avoid confusion ;) so that we can check if a
source, (e.g. the Momento source), can return a DOM. We also need to
extend the URIResolver in the XSLT processor implementation so that it
returns a DOMSource if the input source implements ReadOnlyDOMizable,
SAXSource, if the input source implements XMLizable and StreamSource
othewise. That is all.
>
>>The implementation of the URIResolver that is used is
>>org.apache.excalibur.xml.xslt.XSLTProcessorImpl in its current
>>incarnation it uses the exclaibur source resolver to get the source and
>>then it returns a javax.xml.transform.stream.StreamSource. For use with
>>Momento we need an implemetation of URIResolver that checks if the the
>>source is DOMIzable and in that case returns a
>>javax.xml.transform.dom.DOMSource instead. This can be done by extending
>>the excalibur XSLTProcessorImpl and change the XSLTProcessor in
>>cocoon.xconf.
>
>
> Okay, at this point I think the problem might be that you are
> thinking:
>
> Momento == DOM
>
> Where as I think:
>
> Momento
> |
> +-----------+---+------+--------+--------+
> | | | | |
> W3 DOM Saxon SAX Xalan XUpdate
I don't, but I think it is efficient to view it as a read only DOM when
you want to use XSLT (or XQuery) as a query language for Momento through
JAXP.
>>XQuery
>>======
>
>
>>XQuery in Saxon use a propertary api, (there are no standard in this
>>area yet). So we need a specialized SaxonXQueryGenerator. Saxon use the
>>JAXP URIResolver for XQuery also, so the above described mechanisms can
>>be used here as well. Unfortionatly Saxon is MPL 1.0 that is not
>>compatible with ASL, so we cannot have Saxon as a part of Cocoon :(
>
>
> I am very interested in seeing XQuery become a a first class citizen
> in Cocoon. If Saxon cannot be part of Cocoon and somehow Momento
> can be part of Cocoon, it might be enough to make Saxon pluggable.
>
> I'm really enjoying working with Saxon.
That is the idea for the integration strategy that I propose, all
integration is done at the Jaxp level, so you can use whatether Jaxp
compliant processor together with Momento. Then you can plug in Saxon as
described in http://wiki.cocoondev.org/Wiki.jsp?page=Saxon. For XQuery
the situation is a little bit worse as I described above, as part of the
Saxon implementation of XQuery use things outside Jaxp. We have some
blocks e.g. ojb and web3 that use special mock interfaces for making the
code compilable even if the needed jar not is provided. Maybe this
strategy could be used for the Saxon specific api:s that would be needed
for implementing a XQuery geneerator. I don't know enough about MPL 1.0
to know if it is allowed though. For GPL you are not even allowed to use
mock interfaces IIRC.
/Daniel
Re: Momento and Cocoon
Posted by Alan <al...@engrm.com>.
* Joerg Heinicke <jo...@gmx.de> [2004-03-01 22:48]:
> On 01.03.2004 23:36, Alan wrote:
>
> >>>>>I would guess that Momento mainly would be accessed through the
> >>>>>document function in XSLT and XQuery. Saxon use JAXP 1.1 as external
> >>>>>API to the transformerand the URLs in the document functions are
> >>>>>resolved by using an implementation of javax.xml.transform.URIResolver
> >>>>>that is provided by the TraxTransformer.
> >>>>
> >>>>
> >>>>The above is somewhat confusing for me. Momento does support the
> >>>> JAXP API. XUpdate is implemented as a SAX filter. It seems like
> >>>> Momento would work nicely in as a source, sink, or filter for
> >>>> SAX events.
> >>>>
> >>>> I've imagined that a pipeline would start with a Momento
> >>>> document and an XSLT trasform or XQuery query.
> >>>>
> >>>> Something along these lines:
> >>>>
> >>>> <map:match pattern="index.html">
> >>>> <map:generate type="momento" src="momento.mx"
> >>>> xslt="index-document.xslt"/>
> >>>> <map:transform type="xslt" src="document-to-web.xslt"/>
> >>>> <map:serialize type="html"/>
> >>>> </map:match>
> >>>>
> >>>> (It is easier for me to express myself as a Cocoon user.)
> >>
> >>>It was already mentioned and I only want to repeat it here: Momento
> >>>should not be implemented as generator, but as source. As Momento
> >>>returns also only XML just the file or xml generator should be needed.
> >>>Example:
> >>
> >>You miss the point. Saxon (and in time Xalan) operates directly on
> >> Momento. One uses XSLT or XQuery to build a document from a
> >> potentially HUGE Momento document. The XSLT and XQuery documents
> >> mean that Momento will not even touch parts of the document not
> >> pertiant to the query.
> >>
> >> I do not want to generate SAX events and have Cocoon build an in
> >> memory DOM, and then run an XSLT transform. It misses the point.
> >
> >
> >s/You miss the/I've done poor job of explaining this/
> >
> > Didn't sound the way I wanted it to...
> No problem, I also can live with the original formulation :) The reason
> therefor is simply that I did not follow this thread very closely as I
> had to prepare for some exams.
I do appreciate your interest, especially since I'd like to see
Momento snuggle right up to CForms.
> Now, what exactly is Momento? I saw it only as something similar to a
> XML database with maybe some special features. When having XIndice in
> mind I don't like the idea of having an XSLT or XQuery processor
> operating directly on it (separation of concerns).
SoC is important.
The XSLT is not used to style, but as means to perform joins,
aggregation, grouping, etc. The XSLT is really a query langauge,
like XQuery. This is just to get right format of a document to
get the pipeline going, akin to the aggregator.
SoC is important. I am *not* out to integrate transform and
generation. XSLT as a query language.
(That is, XSLT opimized to use persistant indicies,
optimized to load only those nodes necessary, designed
operate concurrently with other XSLT, XQuery and W3 DOM
queries and XUpdate modifications. Not a transform, but a
nice way to reuse your XSLT skill-set.
)
I choose Saxon for it's XQuery support, but now I've come to see
XSLT as a better query langauge.
I've the combination of data store + query language is a valid
reason to create a generator, and not, I don't think, a mixing
of concerns.
> But maybe here I miss indeed an important point though I see your
> point with huge document and memory DOM. You don't need to explain
> the whole thing again if it was already said, pointing to a link
> or a mail in the archives would be helpful though.
I went and updated the Momento project page:
http://engrm.com/project/com.agtrz.momento/
I tried to punch up the opening section. Everyone please take a
look at tell me how it reads. Ask any questions.
--
Alan / alan@engrm.com / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com
Re: Momento and Cocoon
Posted by Joerg Heinicke <jo...@gmx.de>.
On 01.03.2004 23:36, Alan wrote:
>>>>>I would guess that Momento mainly would be accessed through the document
>>>>>function in XSLT and XQuery. Saxon use JAXP 1.1 as external API to the
>>>>>transformerand the URLs in the document functions are resolved by using
>>>>>an implementation of javax.xml.transform.URIResolver that is provided by
>>>>>the TraxTransformer.
>>>>
>>>>
>>>>The above is somewhat confusing for me. Momento does support the
>>>> JAXP API. XUpdate is implemented as a SAX filter. It seems like
>>>> Momento would work nicely in as a source, sink, or filter for
>>>> SAX events.
>>>>
>>>> I've imagined that a pipeline would start with a Momento
>>>> document and an XSLT trasform or XQuery query.
>>>>
>>>> Something along these lines:
>>>>
>>>> <map:match pattern="index.html">
>>>> <map:generate type="momento" src="momento.mx"
>>>> xslt="index-document.xslt"/>
>>>> <map:transform type="xslt" src="document-to-web.xslt"/>
>>>> <map:serialize type="html"/>
>>>> </map:match>
>>>>
>>>> (It is easier for me to express myself as a Cocoon user.)
>>
>>>It was already mentioned and I only want to repeat it here: Momento
>>>should not be implemented as generator, but as source. As Momento
>>>returns also only XML just the file or xml generator should be needed.
>>>Example:
>>
>>You miss the point. Saxon (and in time Xalan) operates directly on
>> Momento. One uses XSLT or XQuery to build a document from a
>> potentially HUGE Momento document. The XSLT and XQuery documents
>> mean that Momento will not even touch parts of the document not
>> pertiant to the query.
>>
>> I do not want to generate SAX events and have Cocoon build an in
>> memory DOM, and then run an XSLT transform. It misses the point.
>
>
> s/You miss the/I've done poor job of explaining this/
>
> Didn't sound the way I wanted it to...
No problem, I also can live with the original formulation :) The reason
therefor is simply that I did not follow this thread very closely as I
had to prepare for some exams.
Now, what exactly is Momento? I saw it only as something similar to a
XML database with maybe some special features. When having XIndice in
mind I don't like the idea of having an XSLT or XQuery processor
operating directly on it (separation of concerns). But maybe here I miss
indeed an important point though I see your point with huge document and
memory DOM. You don't need to explain the whole thing again if it was
already said, pointing to a link or a mail in the archives would be
helpful though.
Thanks,
Joerg
Re: Momento and Cocoon
Posted by Alan <al...@engrm.com>.
* Alan <al...@engrm.com> [2004-03-01 20:36]:
> * Joerg Heinicke <jo...@gmx.de> [2004-03-01 19:59]:
> > On 26.02.2004 22:04, Alan wrote:
> >
> > >>I would guess that Momento mainly would be accessed through the document
> > >>function in XSLT and XQuery. Saxon use JAXP 1.1 as external API to the
> > >>transformerand the URLs in the document functions are resolved by using
> > >>an implementation of javax.xml.transform.URIResolver that is provided by
> > >>the TraxTransformer.
> > >
> > >
> > >The above is somewhat confusing for me. Momento does support the
> > > JAXP API. XUpdate is implemented as a SAX filter. It seems like
> > > Momento would work nicely in as a source, sink, or filter for
> > > SAX events.
> > >
> > > I've imagined that a pipeline would start with a Momento
> > > document and an XSLT trasform or XQuery query.
> > >
> > > Something along these lines:
> > >
> > > <map:match pattern="index.html">
> > > <map:generate type="momento" src="momento.mx"
> > > xslt="index-document.xslt"/>
> > > <map:transform type="xslt" src="document-to-web.xslt"/>
> > > <map:serialize type="html"/>
> > > </map:match>
> > >
> > > (It is easier for me to express myself as a Cocoon user.)
>
> > It was already mentioned and I only want to repeat it here: Momento
> > should not be implemented as generator, but as source. As Momento
> > returns also only XML just the file or xml generator should be needed.
> > Example:
>
> You miss the point. Saxon (and in time Xalan) operates directly on
> Momento. One uses XSLT or XQuery to build a document from a
> potentially HUGE Momento document. The XSLT and XQuery documents
> mean that Momento will not even touch parts of the document not
> pertiant to the query.
>
> I do not want to generate SAX events and have Cocoon build an in
> memory DOM, and then run an XSLT transform. It misses the point.
s/You miss the/I've done poor job of explaining this/
Didn't sound the way I wanted it to...
--
Alan / alan@engrm.com / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com
Re: Momento and Cocoon
Posted by Alan <al...@engrm.com>.
* Joerg Heinicke <jo...@gmx.de> [2004-03-01 19:59]:
> On 26.02.2004 22:04, Alan wrote:
>
> >>I would guess that Momento mainly would be accessed through the document
> >>function in XSLT and XQuery. Saxon use JAXP 1.1 as external API to the
> >>transformerand the URLs in the document functions are resolved by using
> >>an implementation of javax.xml.transform.URIResolver that is provided by
> >>the TraxTransformer.
> >
> >
> >The above is somewhat confusing for me. Momento does support the
> > JAXP API. XUpdate is implemented as a SAX filter. It seems like
> > Momento would work nicely in as a source, sink, or filter for
> > SAX events.
> >
> > I've imagined that a pipeline would start with a Momento
> > document and an XSLT trasform or XQuery query.
> >
> > Something along these lines:
> >
> > <map:match pattern="index.html">
> > <map:generate type="momento" src="momento.mx"
> > xslt="index-document.xslt"/>
> > <map:transform type="xslt" src="document-to-web.xslt"/>
> > <map:serialize type="html"/>
> > </map:match>
> >
> > (It is easier for me to express myself as a Cocoon user.)
> It was already mentioned and I only want to repeat it here: Momento
> should not be implemented as generator, but as source. As Momento
> returns also only XML just the file or xml generator should be needed.
> Example:
You miss the point. Saxon (and in time Xalan) operates directly on
Momento. One uses XSLT or XQuery to build a document from a
potentially HUGE Momento document. The XSLT and XQuery documents
mean that Momento will not even touch parts of the document not
pertiant to the query.
I do not want to generate SAX events and have Cocoon build an in
memory DOM, and then run an XSLT transform. It misses the point.
> <map:generate src="momento:/document"/>
Fine. We can do that.
> With the mentioned xmldb interface you would write the source just as
> the xindice source and use it like the following ("copied" from xindice
> sample sitemap):
>
> <map:generate src="xmldb:momento://db/document#xpath"/>
Fine we can do that too. But this will only yank out a sub document,
it won't aggregate, join, or filter a document.
> The only thing I don't know exactly how to handle is XQuery. If it is
> used like XSLT we should add a XQueryTransformer later, but if the
> comparison to JXTemplate is more appropriate an XQueryGenerator would be
> needed (maybe both is useful).
XQuery uses the same generator as XSLT. You specify the Momento
docuent and the query to run.
Also keep in mind that Momento can be used throughout the pipeline
returning the document as it was at the start of the pipeline,
which means that XPath can be used against Momento in the
sitemap without worrying about returing inconsistant results.
--
Alan / alan@engrm.com / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com
Re: Momento and Cocoon
Posted by Alan <al...@engrm.com>.
* Stefano Mazzocchi <st...@apache.org> [2004-03-02 17:34]:
> Alan wrote:
>
> >* Stefano Mazzocchi <st...@apache.org> [2004-03-02 14:04]:
> I need an xml database with xquery capabilities to place as a
> slide store for when it will implement JCR.
???
> Xindice is currently my candidate for that, but I'm always open
> for potential alternatives.
By all means use Xindice. Momento is still underdevelopment. It is
not yet ready for production use.
If you want to know more about the design, or the status there
is more information about Momento at my web site.
Cheers.
--
Alan / alan@engrm.com / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com
Re: Momento and Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Alan wrote:
> * Stefano Mazzocchi <st...@apache.org> [2004-03-02 14:04]:
>
>>Alan wrote:
>>
>>
>>>* Stefano Mazzocchi <st...@apache.org> [2004-03-02 06:07]:
>>
>>>>I need a fast and scalable xquery-capable semi-structured content
>>>>repository.
>>>>
>>>>Can momento provide me that?
>>>
>>>
>>> It could. If I were to release it open source. That's the point.
>>> That's why I'm engaging people on this list.
>>>
>>
>>It could seems like a pretty big overestimation without reasonable
>>technological backup.
>
>
>>At least three research groups spent 10 years and millions of dollars
>>trying to build an equivalent system. One of them died (Lore) [but the
>>source code disappeared so I suspect some big DBMS vendor bought the
>>thing], the other went commercial [Xyleme], the other is still
>>researching [the people at Bell Labs]
>
>
> What about Berkeley XML-DB?
doesn't support xquery, its license is incompatible with the ours, it
doesn't scale on multiple machines and the java API is pathetic.
> It seems to be a popular open source database. There is also dbXML, which is now GPL. What about
> Xindice?
doesn't support xquery, hasn't been tested in heavy duty environments,
> I'm not sure what you are expecting. Momento is XQuery capable
> and the content is semi-structured. That took a couple months,
> but nothing like a million dollars.
>
> Fast and scalable? Sure. Why not? If there was a design flaw
> that would prevent concurrent queries or updates, I'm sure it
> would have surfaced by now.
Hmmm, how much data did you have in there?
>>Don't get me wrong: I know the power of open source and I know that you
>>need to start somewhere, that's why I'm asking.
>
>
> Yes. You need to start somewhere.
yep.
> I'm starting out with the organization of the document into
> clusters based on application requirements.
Like xindice collections?
> Michael Kay and I are discussing how to add a simple identity
> key for use with the id attribute and the key element in XSLT.
>
> I'm not going to start with benchmark peformance tests.
Good, if you need tons of xml to test the system let me know.
>>What I don't understand is how you can use Saxon as a fast and scalable
>>database since it wasn't designed to do so.
>
>
> I am using Saxon as a query engine. Momento is a document object model.
>
> Again, I'm not sure what you are expecting. I'm trying not to
> get you wrong.
I need an xml database with xquery capabilities to place as a slide
store for when it will implement JCR.
Xindice is currently my candidate for that, but I'm always open for
potential alternatives.
--
Stefano.
Re: Momento and Cocoon
Posted by Alan <al...@engrm.com>.
* Stefano Mazzocchi <st...@apache.org> [2004-03-02 14:04]:
> Alan wrote:
>
> >* Stefano Mazzocchi <st...@apache.org> [2004-03-02 06:07]:
>
> >>I need a fast and scalable xquery-capable semi-structured content
> >>repository.
> >>
> >>Can momento provide me that?
> >
> >
> > It could. If I were to release it open source. That's the point.
> > That's why I'm engaging people on this list.
> >
>
> It could seems like a pretty big overestimation without reasonable
> technological backup.
> At least three research groups spent 10 years and millions of dollars
> trying to build an equivalent system. One of them died (Lore) [but the
> source code disappeared so I suspect some big DBMS vendor bought the
> thing], the other went commercial [Xyleme], the other is still
> researching [the people at Bell Labs]
What about Berkeley XML-DB? It seems to be a popular open source
database. There is also dbXML, which is now GPL. What about
Xindice?
I'm not sure what you are expecting. Momento is XQuery capable
and the content is semi-structured. That took a couple months,
but nothing like a million dollars.
Fast and scalable? Sure. Why not? If there was a design flaw
that would prevent concurrent queries or updates, I'm sure it
would have surfaced by now.
> Don't get me wrong: I know the power of open source and I know that you
> need to start somewhere, that's why I'm asking.
Yes. You need to start somewhere.
I'm starting out with the organization of the document into
clusters based on application requirements.
Michael Kay and I are discussing how to add a simple identity
key for use with the id attribute and the key element in XSLT.
I'm not going to start with benchmark peformance tests.
> What I don't understand is how you can use Saxon as a fast and scalable
> database since it wasn't designed to do so.
I am using Saxon as a query engine. Momento is a document object model.
Again, I'm not sure what you are expecting. I'm trying not to
get you wrong.
--
Alan / alan@engrm.com / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com
Re: Momento and Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Alan wrote:
> * Stefano Mazzocchi <st...@apache.org> [2004-03-02 06:07]:
>>I need a fast and scalable xquery-capable semi-structured content
>>repository.
>>
>>Can momento provide me that?
>
>
> It could. If I were to release it open source. That's the point.
> That's why I'm engaging people on this list.
>
It could seems like a pretty big overestimation without reasonable
technological backup.
At least three research groups spent 10 years and millions of dollars
trying to build an equivalent system. One of them died (Lore) [but the
source code disappeared so I suspect some big DBMS vendor bought the
thing], the other went commercial [Xyleme], the other is still
researching [the people at Bell Labs]
Don't get me wrong: I know the power of open source and I know that you
need to start somewhere, that's why I'm asking.
What I don't understand is how you can use Saxon as a fast and scalable
database since it wasn't designed to do so.
--
Stefano.
Re: Momento and Cocoon
Posted by Alan <al...@engrm.com>.
* Stefano Mazzocchi <st...@apache.org> [2004-03-02 06:07]:
> Please stop replying to me directly, I far prefer if you reply to the
> list, thanks.
Sorry.
> Alan wrote:
>
> >Yes. I choose Saxon to implement XQuery. I'm finding that XSLT is
> > just as good a query language, that's why I keep using XSLT in
> > my generator examples. Not mixing concerns, it is data store +
> > query, which strikes me as resonable parameters to a generator.
> You can use xslt as a template language for generators but it feels akward.
It makes a lot of sense to me now. XQuery support is there, and
it works, but XSLT does the same thing, and saves the trouble of
learning a new language.
> >>I don't know if momento is good enough for what we need, but if we were
> >>to have an xquery processor, a generator is the way to go, not a source.
> >
> >
> >What do you need from Momento?
>
> I need a fast and scalable xquery-capable semi-structured content
> repository.
>
> Can momento provide me that?
It could. If I were to release it open source. That's the point.
That's why I'm engaging people on this list.
--
Alan / alan@engrm.com / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com
Re: Momento and Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Please stop replying to me directly, I far prefer if you reply to the
list, thanks.
Alan wrote:
> Yes. I choose Saxon to implement XQuery. I'm finding that XSLT is
> just as good a query language, that's why I keep using XSLT in
> my generator examples. Not mixing concerns, it is data store +
> query, which strikes me as resonable parameters to a generator.
You can use xslt as a template language for generators but it feels akward.
>>I don't know if momento is good enough for what we need, but if we were
>>to have an xquery processor, a generator is the way to go, not a source.
>
>
> What do you need from Momento?
I need a fast and scalable xquery-capable semi-structured content
repository.
Can momento provide me that?
--
Stefano.
Re: Momento and Cocoon
Posted by Alan <al...@engrm.com>.
* Stefano Mazzocchi <st...@apache.org> [2004-03-02 03:01]:
> Joerg Heinicke wrote:
>
> >On 26.02.2004 22:04, Alan wrote:
> >
> >>>I would guess that Momento mainly would be accessed through the
> >>>document function in XSLT and XQuery. Saxon use JAXP 1.1 as external
> >>>API to the transformerand the URLs in the document functions are
> >>>resolved by using an implementation of
> >>>javax.xml.transform.URIResolver that is provided by the TraxTransformer.
> >>
> >>
> >>
> >>The above is somewhat confusing for me. Momento does support the
> >> JAXP API. XUpdate is implemented as a SAX filter. It seems like
> >> Momento would work nicely in as a source, sink, or filter for
> >> SAX events.
> >> I've imagined that a pipeline would start with a Momento
> >> document and an XSLT trasform or XQuery query.
> >>
> >> Something along these lines:
> >> <map:match pattern="index.html">
> >> <map:generate type="momento" src="momento.mx"
> >> xslt="index-document.xslt"/>
> >> <map:transform type="xslt" src="document-to-web.xslt"/>
> >> <map:serialize type="html"/>
> >> </map:match>
> >>
> >> (It is easier for me to express myself as a Cocoon user.)
> >
> >
> >It was already mentioned and I only want to repeat it here: Momento
> >should not be implemented as generator, but as source.
>
> I strongly disagree.
>
> XQuery is simply too complex to be passed as one URL. You should have
> something like
>
> <generate type="xquery" src="mystuff.xquery"/>
Yes. I choose Saxon to implement XQuery. I'm finding that XSLT is
just as good a query language, that's why I keep using XSLT in
my generator examples. Not mixing concerns, it is data store +
query, which strikes me as resonable parameters to a generator.
> I don't know if momento is good enough for what we need, but if we were
> to have an xquery processor, a generator is the way to go, not a source.
What do you need from Momento?
--
Alan / alan@engrm.com / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com
Re: Momento and Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Joerg Heinicke wrote:
> On 26.02.2004 22:04, Alan wrote:
>
>>> I would guess that Momento mainly would be accessed through the
>>> document function in XSLT and XQuery. Saxon use JAXP 1.1 as external
>>> API to the transformerand the URLs in the document functions are
>>> resolved by using an implementation of
>>> javax.xml.transform.URIResolver that is provided by the TraxTransformer.
>>
>>
>>
>> The above is somewhat confusing for me. Momento does support the
>> JAXP API. XUpdate is implemented as a SAX filter. It seems like
>> Momento would work nicely in as a source, sink, or filter for
>> SAX events.
>> I've imagined that a pipeline would start with a Momento
>> document and an XSLT trasform or XQuery query.
>>
>> Something along these lines:
>> <map:match pattern="index.html">
>> <map:generate type="momento" src="momento.mx"
>> xslt="index-document.xslt"/>
>> <map:transform type="xslt" src="document-to-web.xslt"/>
>> <map:serialize type="html"/>
>> </map:match>
>>
>> (It is easier for me to express myself as a Cocoon user.)
>
>
> It was already mentioned and I only want to repeat it here: Momento
> should not be implemented as generator, but as source.
I strongly disagree.
XQuery is simply too complex to be passed as one URL. You should have
something like
<generate type="xquery" src="mystuff.xquery"/>
and remember that that xquery is not XML (xqueryx is but that's just
another syntax and it's also verbose and ugly).
xquery is, in fact, not a query language but a very powerful template
language (even if somewhat bloated, if you ask me), it would replace
jxtemplate or garbage.
I don't know if momento is good enough for what we need, but if we were
to have an xquery processor, a generator is the way to go, not a source.
--
Stefano.
Re: Momento and Cocoon
Posted by Joerg Heinicke <jo...@gmx.de>.
On 26.02.2004 22:04, Alan wrote:
>>I would guess that Momento mainly would be accessed through the document
>>function in XSLT and XQuery. Saxon use JAXP 1.1 as external API to the
>>transformerand the URLs in the document functions are resolved by using
>>an implementation of javax.xml.transform.URIResolver that is provided by
>>the TraxTransformer.
>
>
> The above is somewhat confusing for me. Momento does support the
> JAXP API. XUpdate is implemented as a SAX filter. It seems like
> Momento would work nicely in as a source, sink, or filter for
> SAX events.
>
> I've imagined that a pipeline would start with a Momento
> document and an XSLT trasform or XQuery query.
>
> Something along these lines:
>
> <map:match pattern="index.html">
> <map:generate type="momento" src="momento.mx"
> xslt="index-document.xslt"/>
> <map:transform type="xslt" src="document-to-web.xslt"/>
> <map:serialize type="html"/>
> </map:match>
>
> (It is easier for me to express myself as a Cocoon user.)
It was already mentioned and I only want to repeat it here: Momento
should not be implemented as generator, but as source. As Momento
returns also only XML just the file or xml generator should be needed.
Example:
<map:generate src="momento:/document"/>
With the mentioned xmldb interface you would write the source just as
the xindice source and use it like the following ("copied" from xindice
sample sitemap):
<map:generate src="xmldb:momento://db/document#xpath"/>
The only thing I don't know exactly how to handle is XQuery. If it is
used like XSLT we should add a XQueryTransformer later, but if the
comparison to JXTemplate is more appropriate an XQueryGenerator would be
needed (maybe both is useful).
Joerg
Re: Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]
Posted by Alan <al...@engrm.com>.
Responding now after having spent a week in California and a week
working on my web site (http://engrm.com/). Announcing Momento
created a communication burden for me that I am learning how to
shoulder, after a little more work on my web site, I ought to be
able to return to Momento coding.
Cocoon is a large application. I'm primarily familiar with
Cocoon output: pipelines. I'm also familiar with XSLT.
I know nothing of Cocoon internals, and very little about Flow
and CFroms. Although I look forward to learning about both,
the following comments are going to be based on some wild,
unfounded assumptions about Cocoon.
* Daniel Fagerstrom <da...@nada.kth.se> [2004-02-23 15:21]:
> Upayavira wrote:
> >Reinhard Poetz wrote:
> >>From: Alan
> >>>Working on it. As noted, I have JAXP implemented and SAX interface
> >>> to XUpdate. I have APIs. I am going to start working on services
> >>> next.
> >>> A Cocoon generator that takes a Momento data source and an XSLT
> >>> transform would be a start.
> >>>
> >>> I'm not sure how to get information into Momento via Cocoon. I'm
> >>> thinking about some sort of Woody binding, but that goes beyond
> >>> my current understanding of Cocoon.
> >>speaking without following this thread closly: What about implementing
> >>a Momento source?
> >Yup. Alan, take a look at the XMLDBSource and XMLDBSourceFactory. I
> >think you'll find them reasonably similar to what you might want to do
> >(in src/blocks/xmldb/java/org/apache/cocoon/components/source/impl)
> >If you implemented a MomentoSource, and made it implement
> >ModifiableSource, then you would be able to read/write from within
> >Cocoon. With this, you would be able to use Woody's binding
> >functionality to bind forms directly to Momento data.
I really want to see Momento work with CForms.
> >You could also do something like the XMLDBTransformer to allow updates
> >(src/blocks/xmldb/java/org/apache/cocoon/transformation/XMLDBTransformer.java).
> >[NB. with an XML:DB interface to Momento, you wouldn't need to do
> >anything to interface to Cocoon].
Isn't XML:DB deadish?
I wrote Momento because at the time Xindice was zero traffic,
dbXML was propietory, eXist wouldn't install with Cocoon, and
the XML::DB site hadn't been updated in two years.
Also, It doesn't look the like it will make the most of Momento.
I don't like the collections concept, I much prefer one big
document.
Still an XML:DB interface shouldn't be two difficult to implement.
--- In response to Mr. Fagerstrom ---
> Pseudo protocol
> ===============
> In Cocoon (or actually Avalon Excalibur), we have a generalization of
> protocols, java.net.URL, called pseudo protocol
> org.apache.excalibur.source.Source, there are also various extensions of
> Source like ModifiableSource, TraversableSource among others. Pseudo
> protocols are an excelent way of separating the location of data with
> what to do with it. If you package a data source as a pseudo protocol
> you can access it by using its URL, e.g.
> momento://dbpath/collection#xpath(foo/bar), through Cocoons source
> resolver. This makes it possible to use sources for ala src attributes
> in the sitemap, the document function in XSLT and XQuery, hrefs in the
> [X|C]IncludeTransformer, in the SourceWritingTransformer and within
> flowscripts.
> A MomentoSource would thus give a lot of flexibility in using Momento in
> Cocoon. Especially if it allows using XPath(2.0) in the URLs and if it
> is a modifyable source.
Since Momento is pageable, and multi-threaded, you should be able to
yank stuff out of Momento from the sitemap, maybe dumping it
into your pipeline, without parsing a document.
When a Momento URL resolves, it will not require a document to
be loaded an parsed, so it means that thinks like XLink or
XPointer will not suffer that performance hit I read about.
In implementing XLink or XPointer (or whatever) one could read
documents into Momento as an intermediate, caching step.
> XSLT
> ====
> A MomentoSource would also give a good way to use Momento together with
> XSLT and XQuery in Cocoon. Here we need to extend the ordinary use of
> sources somewhat, let me explain:
> The Source interface provides a getInputStream method, in Cocoon some
> Sources implements org.apache.excalibur.xml.sax.XMLizable that provides
> a toSAX method as well. SAX or Streams are probably not the most
> efficient way to communicate with an XML db, so to make the pseudo
> protocol idea usable together with Momento, we should provide a way to
> get a DOM structure from a pseudo protocol. This could be done by
> introducing a new interface:
> interface DOMizable {
> org.w3c.domNode getNode();
> }
Momento, with Cocoon in mind, lends itself to streaming.
Momento would readily support a read-only W3 DOM, but a read write
W3 DOM is quite ugly.
W3 DOM lets you to create inconsistant documents, with is not in
keeping with the C in ACID. (Examples if you want them.) There
is no way to specify the start and end of an atomic transcation
through the DOM API.
Momento uses XUpdate since one can specify a set of modifications,
and Momento can process those modifications as an atomic
transcation. XUpdate expresses all document modifications, and
does so declaratively. Momento can then make logic of you
intentions.
In a pipeline, XML input can be transformed into XUpdate
statement. I suppose one could an XUpdate using JXTemplate from
Flow as well.
XUpdate is really the method of choice for updating Momento.
Both XUpdate and SAX input are a good way to get data into
Momento.
I don't know if you and I talking about the same thing here, but
the sight of org.w3c.domNode leaves me cold. It is a nice
in-memory interface, but a poor interface for persistence.
If W3 DOM were the way to modify a Momento document, the
application developer would have to be prepared to catch all
kinda hel.., er, exceptions, since there are a bunch of stupid
things that Momento won't allow.
> or something similar. If the MomentoSource implements DOMizable, we have
> direct access to nodes in the XML db.
> Now we are prepared to connect Momento to XSLT. In Cocoon we can use
> Saxon through the org.apache.cocoon.transformation.TraxTransformer, you
> just need to change cocoon.xconf a little bit to use Saxon instead of
> Xalan. There is also a TraxGenerator in the scratchpad that could be
> used with some small modifications.
Momento connects to XSLT using a Saxon NodeInfo interface. It could
connect to Xalan just as easily (through read-only W3 DOM?).
> I would guess that Momento mainly would be accessed through the document
> function in XSLT and XQuery. Saxon use JAXP 1.1 as external API to the
> transformerand the URLs in the document functions are resolved by using
> an implementation of javax.xml.transform.URIResolver that is provided by
> the TraxTransformer.
The above is somewhat confusing for me. Momento does support the
JAXP API. XUpdate is implemented as a SAX filter. It seems like
Momento would work nicely in as a source, sink, or filter for
SAX events.
I've imagined that a pipeline would start with a Momento
document and an XSLT trasform or XQuery query.
Something along these lines:
<map:match pattern="index.html">
<map:generate type="momento" src="momento.mx"
xslt="index-document.xslt"/>
<map:transform type="xslt" src="document-to-web.xslt"/>
<map:serialize type="html"/>
</map:match>
(It is easier for me to express myself as a Cocoon user.)
> The implementation of the URIResolver that is used is
> org.apache.excalibur.xml.xslt.XSLTProcessorImpl in its current
> incarnation it uses the exclaibur source resolver to get the source and
> then it returns a javax.xml.transform.stream.StreamSource. For use with
> Momento we need an implemetation of URIResolver that checks if the the
> source is DOMIzable and in that case returns a
> javax.xml.transform.dom.DOMSource instead. This can be done by extending
> the excalibur XSLTProcessorImpl and change the XSLTProcessor in
> cocoon.xconf.
Okay, at this point I think the problem might be that you are
thinking:
Momento == DOM
Where as I think:
Momento
|
+-----------+---+------+--------+--------+
| | | | |
W3 DOM Saxon SAX Xalan XUpdate
> XQuery
> ======
> XQuery in Saxon use a propertary api, (there are no standard in this
> area yet). So we need a specialized SaxonXQueryGenerator. Saxon use the
> JAXP URIResolver for XQuery also, so the above described mechanisms can
> be used here as well. Unfortionatly Saxon is MPL 1.0 that is not
> compatible with ASL, so we cannot have Saxon as a part of Cocoon :(
I am very interested in seeing XQuery become a a first class citizen
in Cocoon. If Saxon cannot be part of Cocoon and somehow Momento
can be part of Cocoon, it might be enough to make Saxon pluggable.
I'm really enjoying working with Saxon.
> --- o0o ---
> Sorry for all the technical details ;)
Thank you for all the technical details.
> See the thread: [RT] the quest for the perfect template language
> http://marc.theaimsgroup.com/?t=104930795600004&r=1&w=2 for a long
> disussion around related ideas.
Long indeed. I'll have to find time to read this. Thank you.
--
Alan / alan@engrm.com / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com
Re: Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Upayavira wrote:
> Reinhard Poetz wrote:
>> From: Alan
>>> Working on it. As noted, I have JAXP implemented and SAX interface
>>> to XUpdate. I have APIs. I am going to start working on services
>>> next.
>>> A Cocoon generator that takes a Momento data source and an XSLT
>>> transform would be a start.
>>>
>>> I'm not sure how to get information into Momento via Cocoon. I'm
>>> thinking about some sort of Woody binding, but that goes beyond
>>> my current understanding of Cocoon.
>>>
>>
>>
>> speaking without following this thread closly: What about implementing
>> a Momento source?
>>
>>
> Yup. Alan, take a look at the XMLDBSource and XMLDBSourceFactory. I
> think you'll find them reasonably similar to what you might want to do
> (in src/blocks/xmldb/java/org/apache/cocoon/components/source/impl)
>
> If you implemented a MomentoSource, and made it implement
> ModifiableSource, then you would be able to read/write from within
> Cocoon. With this, you would be able to use Woody's binding
> functionality to bind forms directly to Momento data.
>
> You could also do something like the XMLDBTransformer to allow updates
> (src/blocks/xmldb/java/org/apache/cocoon/transformation/XMLDBTransformer.java).
>
>
> [NB. with an XML:DB interface to Momento, you wouldn't need to do
> anything to interface to Cocoon].
>
> Hope this helps.
>
> Regards, Upayavira
I agree with the above suggestions and would like to provide some more
technical details.
Pseudo protocol
===============
In Cocoon (or actually Avalon Excalibur), we have a generalization of
protocols, java.net.URL, called pseudo protocol
org.apache.excalibur.source.Source, there are also various extensions of
Source like ModifiableSource, TraversableSource among others. Pseudo
protocols are an excelent way of separating the location of data with
what to do with it. If you package a data source as a pseudo protocol
you can access it by using its URL, e.g.
momento://dbpath/collection#xpath(foo/bar), through Cocoons source
resolver. This makes it possible to use sources for ala src attributes
in the sitemap, the document function in XSLT and XQuery, hrefs in the
[X|C]IncludeTransformer, in the SourceWritingTransformer and within
flowscripts.
A MomentoSource would thus give a lot of flexibility in using Momento in
Cocoon. Especially if it allows using XPath(2.0) in the URLs and if it
is a modifyable source.
XSLT
====
A MomentoSource would also give a good way to use Momento together with
XSLT and XQuery in Cocoon. Here we need to extend the ordinary use of
sources somewhat, let me explain:
The Source interface provides a getInputStream method, in Cocoon some
Sources implements org.apache.excalibur.xml.sax.XMLizable that provides
a toSAX method as well. SAX or Streams are probably not the most
efficient way to communicate with an XML db, so to make the pseudo
protocol idea usable together with Momento, we should provide a way to
get a DOM structure from a pseudo protocol. This could be done by
introducing a new interface:
interface DOMizable {
org.w3c.domNode getNode();
}
or something similar. If the MomentoSource implements DOMizable, we have
direct access to nodes in the XML db.
Now we are prepared to connect Momento to XSLT. In Cocoon we can use
Saxon through the org.apache.cocoon.transformation.TraxTransformer, you
just need to change cocoon.xconf a little bit to use Saxon instead of
Xalan. There is also a TraxGenerator in the scratchpad that could be
used with some small modifications.
I would guess that Momento mainly would be accessed through the document
function in XSLT and XQuery. Saxon use JAXP 1.1 as external API to the
transformerand the URLs in the document functions are resolved by using
an implementation of javax.xml.transform.URIResolver that is provided by
the TraxTransformer.
The implementation of the URIResolver that is used is
org.apache.excalibur.xml.xslt.XSLTProcessorImpl in its current
incarnation it uses the exclaibur source resolver to get the source and
then it returns a javax.xml.transform.stream.StreamSource. For use with
Momento we need an implemetation of URIResolver that checks if the the
source is DOMIzable and in that case returns a
javax.xml.transform.dom.DOMSource instead. This can be done by extending
the excalibur XSLTProcessorImpl and change the XSLTProcessor in
cocoon.xconf.
XQuery
======
XQuery in Saxon use a propertary api, (there are no standard in this
area yet). So we need a specialized SaxonXQueryGenerator. Saxon use the
JAXP URIResolver for XQuery also, so the above described mechanisms can
be used here as well. Unfortionatly Saxon is MPL 1.0 that is not
compatible with ASL, so we cannot have Saxon as a part of Cocoon :(
--- o0o ---
Sorry for all the technical details ;)
As you can see, for reading from Momento, the only Momento specific code
is in the MomentoSource, everything else is using DOM, JAXP and Cocoon
APIs. Therefore the proposed mechanisms would give an efficient way of
using XSLT and XQuery on all data structure that have a DOM interface
and is accessable through a pseudo protocol. See the thread: [RT] the
quest for the perfect template language
http://marc.theaimsgroup.com/?t=104930795600004&r=1&w=2 for a long
disussion around related ideas.
I would love to see the proposed mechanisms in Cocoon.
/Daniel
RE: Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]
Posted by Reinhard Poetz <re...@apache.org>.
From: Upayavira
> >speaking without following this thread closly:
> >What about implementing a Momento source?
> >
> >
> Yup. Alan, take a look at the XMLDBSource and XMLDBSourceFactory. I
> think you'll find them reasonably similar to what you might
> want to do
> (in src/blocks/xmldb/java/org/apache/cocoon/components/source/impl)
>
> If you implemented a MomentoSource, and made it implement
> ModifiableSource, then you would be able to read/write from within
> Cocoon. With this, you would be able to use Woody's binding
> functionality to bind forms directly to Momento data.
>
> You could also do something like the XMLDBTransformer to
> allow updates
> (src/blocks/xmldb/java/org/apache/cocoon/transformation/XMLDBT
> ransformer.java).
>
> [NB. with an XML:DB interface to Momento, you wouldn't need to do
> anything to interface to Cocoon].
>
> Hope this helps.
Thanks, this is exactly what I was thinking of!
Best,
Reinhard
Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]
Posted by Upayavira <uv...@upaya.co.uk>.
[changing subject...]
Reinhard Poetz wrote:
>From: Alan
>
>
>
>>* Geoff Howard <co...@leverageweb.com> [2004-02-22 18:47]:
>>
>>
>>>Alan wrote:
>>>
>>>
>>>
>>>>* Upayavira <uv...@upaya.co.uk> [2004-02-22 07:58]:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I tend to think that Momento isn't suited to this need.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>>However, as an XML data repository, it seems very interesting.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I've got a better idea of how Jisp is used in Cocoon from reading
>>>> all the discussion after my post.
>>>>
>>>> I suggested Momento because someone suggested Xindice which led
>>>> me to believe Jisp handled an XML persistence task.
>>>>
>>>> Might not be the best bet, no.
>>>>
>>>>
>>>>
>>>>
>>>Still, I think finding a way to use momento to reduce
>>>
>>>
>>memory overhead
>>
>>
>>>in
>>>working with large xml datasets has great potential. No one really
>>>knows how great, but a demo/sample using it would be a
>>>
>>>
>>start... (hint
>>
>>
>>>hint :) )
>>>
>>>
>>Working on it. As noted, I have JAXP implemented and SAX interface
>> to XUpdate. I have APIs. I am going to start working on services
>> next.
>>
>> A Cocoon generator that takes a Momento data source and an XSLT
>> transform would be a start.
>>
>> I'm not sure how to get information into Momento via Cocoon. I'm
>> thinking about some sort of Woody binding, but that goes beyond
>> my current understanding of Cocoon.
>>
>>
>
>speaking without following this thread closly:
>What about implementing a Momento source?
>
>
Yup. Alan, take a look at the XMLDBSource and XMLDBSourceFactory. I
think you'll find them reasonably similar to what you might want to do
(in src/blocks/xmldb/java/org/apache/cocoon/components/source/impl)
If you implemented a MomentoSource, and made it implement
ModifiableSource, then you would be able to read/write from within
Cocoon. With this, you would be able to use Woody's binding
functionality to bind forms directly to Momento data.
You could also do something like the XMLDBTransformer to allow updates
(src/blocks/xmldb/java/org/apache/cocoon/transformation/XMLDBTransformer.java).
[NB. with an XML:DB interface to Momento, you wouldn't need to do
anything to interface to Cocoon].
Hope this helps.
Regards, Upayavira
RE: Jisp 3.0 moved to GPL licence
Posted by Reinhard Poetz <re...@apache.org>.
From: Alan
> * Geoff Howard <co...@leverageweb.com> [2004-02-22 18:47]:
> > Alan wrote:
> >
> > >* Upayavira <uv...@upaya.co.uk> [2004-02-22 07:58]:
> > >
> > >
> > >
> > >>I tend to think that Momento isn't suited to this need.
> > >>
> > >>
> > >
> > >
> > >
> > >>However, as an XML data repository, it seems very interesting.
> > >>
> > >>
> > >
> > >I've got a better idea of how Jisp is used in Cocoon from reading
> > > all the discussion after my post.
> > >
> > > I suggested Momento because someone suggested Xindice which led
> > > me to believe Jisp handled an XML persistence task.
> > >
> > > Might not be the best bet, no.
> > >
> > >
> >
> > Still, I think finding a way to use momento to reduce
> memory overhead
> > in
> > working with large xml datasets has great potential. No one really
> > knows how great, but a demo/sample using it would be a
> start... (hint
> > hint :) )
>
> Working on it. As noted, I have JAXP implemented and SAX interface
> to XUpdate. I have APIs. I am going to start working on services
> next.
>
> A Cocoon generator that takes a Momento data source and an XSLT
> transform would be a start.
>
> I'm not sure how to get information into Momento via Cocoon. I'm
> thinking about some sort of Woody binding, but that goes beyond
> my current understanding of Cocoon.
speaking without following this thread closly:
What about implementing a Momento source?
--
Reinhard
Re: Jisp 3.0 moved to GPL licence
Posted by Alan <al...@engrm.com>.
* Geoff Howard <co...@leverageweb.com> [2004-02-22 18:47]:
> Alan wrote:
>
> >* Upayavira <uv...@upaya.co.uk> [2004-02-22 07:58]:
> >
> >
> >
> >>I tend to think that Momento isn't suited to this need.
> >>
> >>
> >
> >
> >
> >>However, as an XML data repository, it seems very interesting.
> >>
> >>
> >
> >I've got a better idea of how Jisp is used in Cocoon from reading
> > all the discussion after my post.
> >
> > I suggested Momento because someone suggested Xindice which led
> > me to believe Jisp handled an XML persistence task.
> >
> > Might not be the best bet, no.
> >
> >
>
> Still, I think finding a way to use momento to reduce memory overhead in
> working with large xml datasets has great potential. No one really
> knows how great, but a demo/sample using it would be a start... (hint
> hint :) )
Working on it. As noted, I have JAXP implemented and SAX interface
to XUpdate. I have APIs. I am going to start working on services
next.
A Cocoon generator that takes a Momento data source and an XSLT
transform would be a start.
I'm not sure how to get information into Momento via Cocoon. I'm
thinking about some sort of Woody binding, but that goes beyond
my current understanding of Cocoon.
You can now download and build Momento:
http://engrm.com/project/com.agtrz.momento/
Click on download. Download the ZIP. You need Ant 1.6.
ant -f mix.bootstrap.xml
ant mix.distribution
That ought to do it.
--
Alan / alan@engrm.com / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com
Re: Jisp 3.0 moved to GPL licence
Posted by Geoff Howard <co...@leverageweb.com>.
Alan wrote:
>* Upayavira <uv...@upaya.co.uk> [2004-02-22 07:58]:
>
>
>
>>I tend to think that Momento isn't suited to this need.
>>
>>
>
>
>
>>However, as an XML data repository, it seems very interesting.
>>
>>
>
>I've got a better idea of how Jisp is used in Cocoon from reading
> all the discussion after my post.
>
> I suggested Momento because someone suggested Xindice which led
> me to believe Jisp handled an XML persistence task.
>
> Might not be the best bet, no.
>
>
Still, I think finding a way to use momento to reduce memory overhead in
working with large xml datasets has great potential. No one really
knows how great, but a demo/sample using it would be a start... (hint
hint :) )
Geoff
Re: Jisp 3.0 moved to GPL licence
Posted by Alan <al...@engrm.com>.
* Upayavira <uv...@upaya.co.uk> [2004-02-22 07:58]:
> Alan wrote:
>
> >* Antonio Gallardo <ag...@agssa.net> [2004-02-20 11:25]:
> >
> >
> >>Reinhard Poetz dijo:
> >>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.
> >Can I suggest moving to Momento?
> Alan, whilst I _am_ very interested to read about Momento, I do wonder
> if it is what we need for our caching persistence engine. I would
> describe that as primarily a binary data store, while sometimes storing
> XML.
> The cache sometimes stores XML part way through a pipeline, but usually
> stores the serialised result of a page, which may be in any format (i.e.
> binary).
> I tend to think that Momento isn't suited to this need.
> However, as an XML data repository, it seems very interesting.
I've got a better idea of how Jisp is used in Cocoon from reading
all the discussion after my post.
I suggested Momento because someone suggested Xindice which led
me to believe Jisp handled an XML persistence task.
Might not be the best bet, no.
Cheers.
--
Alan / alan@engrm.com / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com
Re: Jisp 3.0 moved to GPL licence
Posted by Upayavira <uv...@upaya.co.uk>.
Alan wrote:
>* Antonio Gallardo <ag...@agssa.net> [2004-02-20 11:25]:
>
>
>>Reinhard Poetz dijo:
>>
>>
>>>>Am 14:01 10.02.2004 -0500 schrieb Steve Krulewitz:
>>>>
>>>>
>>>>>Does anyone know what happened to the jisp website? The old URL
>>>>>http://www.coyotegulch.com/jisp/index.html sends you to an
>>>>>
>>>>>
>>>>invalid link.
>>>>
>>>>It's back up now: http://www.coyotegulch.com/jisp/
>>>>I never went there before it went down, but it now has a
>>>>version 3.0.0. That version isn't under the old license
>>>>anymore but GPLed (or commercial
>>>>for 2500$).
>>>>Old versions I can't find there..
>>>>
>>>>gunnar
>>>>
>>>>ps: sorry if you get this mail twice, steve. small mistake by me.
>>>>
>>>>--
>>>>G. Brand - interface:projects GmbH
>>>>
>>>>
>>>As our store depends on Jisp - what does this mean for us? IMO we have
>>>to look for a replacement. Any ideas/hints?
>>>
>>>
>>AFAIK, we must move away from jisp. That was an ugly move! :-(
>>
>>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.
>>
>>
>
>Can I suggest moving to Momento?
>
Alan, whilst I _am_ very interested to read about Momento, I do wonder
if it is what we need for our caching persistence engine. I would
describe that as primarily a binary data store, while sometimes storing
XML.
The cache sometimes stores XML part way through a pipeline, but usually
stores the serialised result of a page, which may be in any format (i.e.
binary).
I tend to think that Momento isn't suited to this need.
However, as an XML data repository, it seems very interesting.
Regards,
Upayavira
<snip/>
Re: Jisp 3.0 moved to GPL licence
Posted by Alan <al...@engrm.com>.
* Antonio Gallardo <ag...@agssa.net> [2004-02-20 11:25]:
> Reinhard Poetz dijo:
> >
> >> Am 14:01 10.02.2004 -0500 schrieb Steve Krulewitz:
> >> >Does anyone know what happened to the jisp website? The old URL
> >> >http://www.coyotegulch.com/jisp/index.html sends you to an
> >> invalid link.
> >>
> >> It's back up now: http://www.coyotegulch.com/jisp/
> >> I never went there before it went down, but it now has a
> >> version 3.0.0. That version isn't under the old license
> >> anymore but GPLed (or commercial
> >> for 2500$).
> >> Old versions I can't find there..
> >>
> >> gunnar
> >>
> >> ps: sorry if you get this mail twice, steve. small mistake by me.
> >>
> >> --
> >> G. Brand - interface:projects GmbH
> >
> >
> > As our store depends on Jisp - what does this mean for us? IMO we have
> > to look for a replacement. Any ideas/hints?
> AFAIK, we must move away from jisp. That was an ugly move! :-(
>
> 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.
Can I suggest moving to Momento?
I've been working on Momento solid since mid-November. I'll
continue to move forward with it at a good clip, hopefully with
help from the Apache community. It's where I'm at.
I have developed Momento in the hopes that the Apache XML
community take a shine to it. If so, I'd make sure to have an
Apache compatable license, if not the Apache 2.0 license itself.
As a reminder, Momento is an XML persistence engine.
It is API agnostic. It currently supports XQuery 1.0 and XSLT
2.0 (via Saxon) and XUpdate. It can support other APIs and query
engines, no problem (SAX, Xalan, W3 DOM, and Jaxen have been
explored).
It is a transactional data store. It provides ACID storage for
XML (Atomic, Consitsant, Isolated, and Durable). It is designed
to commit multipe updates an an atomic transaction and recover
from hard shut downs to the last commited transaction.
It is scaleable, since it supports multiple concurrent queries,
and (with some educated decisions by the application designer)
concurrent updates. It is a thread safe persistence engine.
For the future, Momento will support indices, multi-process
opreation, and access control lists.
Again, this work is core to my career. I'm all over it. Cocoon
is another focus. Technically, Momento and Cocoon are going to
play nice. Legally too, just as long as I understand the issues.
http://engrm.com/project/com.agtrz.momento/
I am posting a zip distribution right now.
--
Alan / alan@engrm.com / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com
Re: Jisp 3.0 moved to GPL licence
Posted by Antonio Gallardo <ag...@agssa.net>.
Reinhard Poetz dijo:
>
>> Am 14:01 10.02.2004 -0500 schrieb Steve Krulewitz:
>> >Does anyone know what happened to the jisp website? The old URL
>> >http://www.coyotegulch.com/jisp/index.html sends you to an
>> invalid link.
>>
>> It's back up now: http://www.coyotegulch.com/jisp/
>> I never went there before it went down, but it now has a
>> version 3.0.0. That version isn't under the old license
>> anymore but GPLed (or commercial
>> for 2500$).
>> Old versions I can't find there..
>>
>> gunnar
>>
>> ps: sorry if you get this mail twice, steve. small mistake by me.
>>
>> --
>> G. Brand - interface:projects GmbH
>
>
> As our store depends on Jisp - what does this mean for us? IMO we have
> to look for a replacement. Any ideas/hints?
AFAIK, we must move away from jisp. That was an ugly move! :-(
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.
WDYT?
Best Regards,
Antonio Gallardo.
Re: Jisp 3.0 moved to GPL licence
Posted by Steven Noels <st...@outerthought.org>.
On 22 Feb 2004, at 14:30, Pier Fumagalli wrote:
> Is 2.2 still trying to be compatible with J2SE 1.3 or we can safely
> assume that 1.4 is going to be a J2SE 1.4 only release?
I'm +1 on 1.4 for 2.2.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
RE: Jisp 3.0 moved to GPL licence
Posted by Reinhard Poetz <re...@apache.org>.
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> Sent: Sunday, February 22, 2004 4:06 PM
> To: dev@cocoon.apache.org
> Subject: RE: Jisp 3.0 moved to GPL licence
>
>
> Pier Fumagalli wrote:
> >
> > Is 2.2 still trying to be compatible with J2SE 1.3 or we can
> > safely assume that 1.4 is going to be a J2SE 1.4 only release?
> >
> We haven't discussed/decided this :) If 1.4 is available on
> all important plattforms than there is nothing imho against
> using 1.4 features. Until now, we didn't have the need and
> could live with what 1.3 provides us.
+1
As long as there is no concrete need (= features that are not available
with 1.3 or a third party library) I tend to support 1.3 as long as
possible. Escpecially big companies wait with software upgrades very
long ...
--
Reinhard
RE: Jisp 3.0 moved to GPL licence
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Pier Fumagalli wrote:
>
> Is 2.2 still trying to be compatible with J2SE 1.3 or we can
> safely assume that 1.4 is going to be a J2SE 1.4 only release?
>
We haven't discussed/decided this :) If 1.4 is available on all
important plattforms than there is nothing imho against using
1.4 features.
Until now, we didn't have the need and could live with what 1.3
provides us.
Carsten
Re: Jisp 3.0 moved to GPL licence
Posted by Pier Fumagalli <pi...@betaversion.org>.
Is 2.2 still trying to be compatible with J2SE 1.3 or we can safely
assume that 1.4 is going to be a J2SE 1.4 only release?
Pier (pondering on memory mappings)
On 20 Feb 2004, at 10:52, Reinhard Poetz wrote:
>
>> Am 14:01 10.02.2004 -0500 schrieb Steve Krulewitz:
>>> Does anyone know what happened to the jisp website? The old URL
>>> http://www.coyotegulch.com/jisp/index.html sends you to an
>> invalid link.
>>
>> It's back up now: http://www.coyotegulch.com/jisp/
>> I never went there before it went down, but it now has a
>> version 3.0.0. That version isn't under the old license
>> anymore but GPLed (or commercial
>> for 2500$).
>> Old versions I can't find there..
>>
>> gunnar
>>
>> ps: sorry if you get this mail twice, steve. small mistake by me.
>>
>> --
>> G. Brand - interface:projects GmbH
>
>
> As our store depends on Jisp - what does this mean for us? IMO we have
> to look for a replacement. Any ideas/hints?
>
> --
> Reinhard
>
>
Re: Jisp 3.0 moved to GPL licence
Posted by Geoff Howard <co...@leverageweb.com>.
Reinhard Poetz wrote:
>As our store depends on Jisp - what does this mean for us? IMO we have
>to look for a replacement. Any ideas/hints?
>
>
This is not stricly true, is it? We use by default the JISP persistent
store implementation, but it's a config entry away to switch to the file
system store or any other. IIRC from the discussion at the time (Vadim
did this good work, no?) there was a performance improvement but I
haven't yet located the discussion to determine how much.
Geoff
RE: Jisp 3.0 moved to GPL licence
Posted by Antonio Gallardo <ag...@agssa.net>.
Carsten Ziegeler dijo:
> What about JCS?
>
> http://jakarta.apache.org/turbine/jcs/index.html
Thanks Carsten!
Looks like the right tool for the right work! :-DDD
In short, here is my: +1
Best Regards,
Antonio Gallardo
Re: Jisp 3.0 moved to GPL licence
Posted by Torsten Curdt <tc...@vafer.org>.
> Hi Torsten!
>
> Long time don't saw a post from you. Welcome back!
Geez ...that's nice welcome :D
(I was only lurking for few days)
God, I love this people here :)
> It is a good idea. I think this is the best we can do. Also I think we
> will need a database to replace jisp, I thought another good candidate can
> be hsqldb (already on out CVS) or - Axion
> http://axion.tigris.org/quickstart.html
(Any particular reason to switch here, too?)
I don't have a very good overview
about what's out there but I like
JCS for several reasons:
a) it's an apache project
b) caching is it's primary project goal
c) server clustering and remote synchronization
Of course they have the same problem with
the licence change (in the future) ...but
they *have* to deal with it too. Why not help
them and give us some more features at the
same time? BUT!
Unfortunately looking at the changelog
and the list of project members the
project seems to be... well...
not very active :-/
Hm...
--
Torsten
Re: Jisp 3.0 moved to GPL licence
Posted by Antonio Gallardo <ag...@agssa.net>.
Stefano Mazzocchi dijo:
> Antonio Gallardo wrote:
>
>> Torsten Curdt dijo:
>>
>>>Antonio Gallardo wrote:
>>>
>>>
>>>>Carsten Ziegeler dijo:
>>>>
>>>>
>>>>>What about JCS?
>>>>>
>>>>>http://jakarta.apache.org/turbine/jcs/index.html
>>>>
>>>>
>>>>jisp is part of the dependencies. :-(
>>>>See:
>>>>http://jakarta.apache.org/turbine/jcs/dependencies.html
>>>
>>>hm... what do they do?
>>>maybe we should talk to them and coordinate efforts?
>>
>> Hi Torsten!
>>
>> Long time don't saw a post from you. Welcome back!
>>
>> It is a good idea. I think this is the best we can do. Also I think we
>> will need a database to replace jisp, I thought another good candidate
>> can
>> be hsqldb (already on out CVS) or - Axion
>> http://axion.tigris.org/quickstart.html
>>
>> WDYT?
>>
>> Best Regards,
>>
>> Antonio Gallardo
>
> Antonio, Jisp is not a database! is a binary object storage system. The
> closest thing I can think of is BerkeleyDB or, in short, a persistent
> hashtable.
>
> That's all we need.
Yep. This is a not good option. Thanks for the advise! :-D
Best Regards,
Antonio Gallardo
Re: Jisp 3.0 moved to GPL licence
Posted by Stefano Mazzocchi <st...@apache.org>.
Antonio Gallardo wrote:
> Torsten Curdt dijo:
>
>>Antonio Gallardo wrote:
>>
>>
>>>Carsten Ziegeler dijo:
>>>
>>>
>>>>What about JCS?
>>>>
>>>>http://jakarta.apache.org/turbine/jcs/index.html
>>>
>>>
>>>jisp is part of the dependencies. :-(
>>>See:
>>>http://jakarta.apache.org/turbine/jcs/dependencies.html
>>
>>hm... what do they do?
>>maybe we should talk to them and coordinate efforts?
>
> Hi Torsten!
>
> Long time don't saw a post from you. Welcome back!
>
> It is a good idea. I think this is the best we can do. Also I think we
> will need a database to replace jisp, I thought another good candidate can
> be hsqldb (already on out CVS) or - Axion
> http://axion.tigris.org/quickstart.html
>
> WDYT?
>
> Best Regards,
>
> Antonio Gallardo
Antonio, Jisp is not a database! is a binary object storage system. The
closest thing I can think of is BerkeleyDB or, in short, a persistent
hashtable.
That's all we need.
--
Stefano.
Re: Jisp 3.0 moved to GPL licence
Posted by Antonio Gallardo <ag...@agssa.net>.
Torsten Curdt dijo:
> Antonio Gallardo wrote:
>
>> Carsten Ziegeler dijo:
>>
>>>What about JCS?
>>>
>>>http://jakarta.apache.org/turbine/jcs/index.html
>>
>>
>> jisp is part of the dependencies. :-(
>> See:
>> http://jakarta.apache.org/turbine/jcs/dependencies.html
>
> hm... what do they do?
> maybe we should talk to them and coordinate efforts?
Hi Torsten!
Long time don't saw a post from you. Welcome back!
It is a good idea. I think this is the best we can do. Also I think we
will need a database to replace jisp, I thought another good candidate can
be hsqldb (already on out CVS) or - Axion
http://axion.tigris.org/quickstart.html
WDYT?
Best Regards,
Antonio Gallardo
Re: Jisp 3.0 moved to GPL licence
Posted by Antonio Gallardo <ag...@agssa.net>.
Steven Noels dijo:
> On 20 Feb 2004, at 12:52, Torsten Curdt wrote:
>
>> hm... what do they do?
>> maybe we should talk to them and coordinate efforts?
>
> +1 - seems like the best plan to go forward without over-reacting.
I will try to contact the Apache JCS community. Seems like the development
stalled since 2003-08-21:
http://jakarta.apache.org/turbine/jcs/changelog-report.html
There are 2 committers:
http://jakarta.apache.org/turbine/jcs/team-list.html
Looks like we will need to give them a hand. :-D
Best Regards,
Antonio Gallardo
Re: Jisp 3.0 moved to GPL licence
Posted by Antonio Gallardo <ag...@agssa.net>.
Steven Noels dijo:
> On 20 Feb 2004, at 12:52, Torsten Curdt wrote:
>
>> hm... what do they do?
>> maybe we should talk to them and coordinate efforts?
>
> +1 - seems like the best plan to go forward without over-reacting.
Did we need a VOTE?
Good news!
I already read some info of JCS and looks like the jisp usage is optional:
http://jakarta.apache.org/turbine/jcs/JCSPackageInformation.html
In this document under "Auxiliary caches":
o.a.s.j.auxiliary.disk
---------------------
The primary disk auxiliary. Objects are serialized to a file on disk. This
implementation uses memory keys and performs quite well. Recomended for
most cases.
o.a.s.j.auxiliary.disk.jisp
---------------------------
Disk cache implemented with the Java Indexed Serialization Package , which
allows serialization of objects to B-Tree indexed tables on disk. This is
quite slow currently.
o.a.s.j.auxiliary.disk.hsql
---------------------------
A disk cache using Hypersonic SQL to serialize the contained objects.
Hope this help.
Best Regards,
Antonio Gallardo
RE: Jisp 3.0 moved to GPL licence
Posted by Antonio Gallardo <ag...@agssa.net>.
Reinhard Poetz dijo:
>
>
>> -----Original Message-----
>> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>> Sent: Friday, February 20, 2004 3:55 PM
>> To: dev@cocoon.apache.org
>> Subject: Re: Jisp 3.0 moved to GPL licence
>>
>>
>> Steven Noels wrote:
>>
>> > On 20 Feb 2004, at 12:52, Torsten Curdt wrote:
>> >
>> >> hm... what do they do?
>> >> maybe we should talk to them and coordinate efforts?
>> >
>> >
>> > +1 - seems like the best plan to go forward without over-reacting.
>> >
>> > FWIW: I think we should actively weed out one-man-effort
>> dependencies.
>> > People have the freedom to change their mind, but we shouldn't be a
>> > victim of that.
>>
>> +1000
>>
>> But keep in mind that we are never locked in as we always
>> have the right
>> to fork. So, let's keep reasonable and not panic.
>
> +1
> As Antonio already said it's no emergency becaue we *do use* a former
> version under a 'friendly' licency and we have time to evaluate all
> possible options without getting panic. For now this is
>
> - forking Jisp 2.6
> - JCS
> - OSCache from Opensymphonie
>
> Some mentioned RDBMS systems or XMLDBs - of course an option but I don't
> think they are designed for our caching needs (but maybe I'm wrong
> here).
I will prefer to eat our own "dog food". I think Apache JCS is a good
candidate. If there are bugs, let fix them! Please keep in mind that
excalibur need to be changed too.
Best Regards,
Antonio Gallardo
Re: Jisp 3.0 moved to GPL licence
Posted by Joerg Heinicke <jo...@gmx.de>.
On 20.02.2004 21:18, Ryan Hoegg wrote:
> - Prevayler (http://www.prevayler.org/wiki.jsp)
Also LGPL.
Joerg
Re: Jisp 3.0 moved to GPL licence
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Also add to this list:
- Xindice Filer (mentioned in subsequent posts)
- Prevayler (http://www.prevayler.org/wiki.jsp)
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net/
Reinhard Poetz wrote:
>As Antonio already said it's no emergency becaue we *do use* a former
>version under a 'friendly' licency and we have time to evaluate all
>possible options without getting panic. For now this is
>
> - forking Jisp 2.6
> - JCS
> - OSCache from Opensymphonie
>
>Some mentioned RDBMS systems or XMLDBs - of course an option but I don't
>think they are designed for our caching needs (but maybe I'm wrong
>here).
>
>--
>Reinhard
>
>
>
RE: Jisp 3.0 moved to GPL licence
Posted by Reinhard Poetz <re...@apache.org>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Friday, February 20, 2004 3:55 PM
> To: dev@cocoon.apache.org
> Subject: Re: Jisp 3.0 moved to GPL licence
>
>
> Steven Noels wrote:
>
> > On 20 Feb 2004, at 12:52, Torsten Curdt wrote:
> >
> >> hm... what do they do?
> >> maybe we should talk to them and coordinate efforts?
> >
> >
> > +1 - seems like the best plan to go forward without over-reacting.
> >
> > FWIW: I think we should actively weed out one-man-effort
> dependencies.
> > People have the freedom to change their mind, but we shouldn't be a
> > victim of that.
>
> +1000
>
> But keep in mind that we are never locked in as we always
> have the right
> to fork. So, let's keep reasonable and not panic.
+1
As Antonio already said it's no emergency becaue we *do use* a former
version under a 'friendly' licency and we have time to evaluate all
possible options without getting panic. For now this is
- forking Jisp 2.6
- JCS
- OSCache from Opensymphonie
Some mentioned RDBMS systems or XMLDBs - of course an option but I don't
think they are designed for our caching needs (but maybe I'm wrong
here).
--
Reinhard
Re: Jisp 3.0 moved to GPL licence
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:
> On 20 Feb 2004, at 12:52, Torsten Curdt wrote:
>
>> hm... what do they do?
>> maybe we should talk to them and coordinate efforts?
>
>
> +1 - seems like the best plan to go forward without over-reacting.
>
> FWIW: I think we should actively weed out one-man-effort dependencies.
> People have the freedom to change their mind, but we shouldn't be a
> victim of that.
+1000
But keep in mind that we are never locked in as we always have the right
to fork. So, let's keep reasonable and not panic.
--
Stefano.
Re: Jisp 3.0 moved to GPL licence
Posted by Steven Noels <st...@outerthought.org>.
On 20 Feb 2004, at 12:52, Torsten Curdt wrote:
> hm... what do they do?
> maybe we should talk to them and coordinate efforts?
+1 - seems like the best plan to go forward without over-reacting.
FWIW: I think we should actively weed out one-man-effort dependencies.
People have the freedom to change their mind, but we shouldn't be a
victim of that.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Jisp 3.0 moved to GPL licence
Posted by Torsten Curdt <tc...@vafer.org>.
Antonio Gallardo wrote:
> Carsten Ziegeler dijo:
>
>>What about JCS?
>>
>>http://jakarta.apache.org/turbine/jcs/index.html
>
>
> jisp is part of the dependencies. :-(
> See:
> http://jakarta.apache.org/turbine/jcs/dependencies.html
hm... what do they do?
maybe we should talk to them and coordinate efforts?
--
Torsten
RE: Jisp 3.0 moved to GPL licence
Posted by Antonio Gallardo <ag...@agssa.net>.
Carsten Ziegeler dijo:
> What about JCS?
>
> http://jakarta.apache.org/turbine/jcs/index.html
jisp is part of the dependencies. :-(
See:
http://jakarta.apache.org/turbine/jcs/dependencies.html
Best Regards,
Antonio Gallardo
RE: Jisp 3.0 moved to GPL licence
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Gunnar:
We understand this is not an emergency. Instead, this is an alert that we
need to change. Of course we will evaluate the best replacement and do
switch as quick as we can. AFAIK, almost every piece of software is far to
be perfect and it is improved or have bug fixes on veery new release. In
that way, it is clear to me that we cannot continue the use of jisp in
Cocoon.
Best Regards,
Antonio Gallardo.
Gunnar Brand dijo:
> Am 05:39 20.02.2004 -0600 schrieb Antonio Gallardo:
>>Carsten Ziegeler dijo:
>> > What about JCS?
>> >
>> > http://jakarta.apache.org/turbine/jcs/index.html
>>
>>jisp is part of the dependencies. :-(
>>See:
>>http://jakarta.apache.org/turbine/jcs/dependencies.html
>>
>>Best Regards,
>>
>>Antonio Gallardo
>
> I wrote that version 3.0.0 is GPLed.
>
> If you read http://www.coyotegulch.com/jisp/license_policy.html carefully,
> you will notice that it says
> "Older Versions
> Older versions of Jisp use different licenses; those licenses only apply
> to
> Jisp version 2.6 and earlier. Jisp 3.0.0 is licensed under new terms, and
> old terms from the previous version may not be applied to Jisp version
> 3.0.0 or later."
>
> IMHO as long as the old jisp (v2.6 or lower) is used, nothing needs to
> change. No updates anymore, though.
>
> gunnar
>
>
>
> --
> G. Brand - interface:projects GmbH
> Tolkewitzer Strasse 49
> D-01277 Dresden
> mail: g.brand@interface-projects.de
> tel: ++49-351-3 18 09 - 41
>
> Ein Unternehmen der interface:business-Gruppe
>
RE: Jisp 3.0 moved to GPL licence
Posted by Reinhard Poetz <re...@apache.org>.
From: Gunnar Brand [mailto:g.brand@interface-business.de]
> Am 05:39 20.02.2004 -0600 schrieb Antonio Gallardo:
> >Carsten Ziegeler dijo:
> > > What about JCS?
> > >
> > > http://jakarta.apache.org/turbine/jcs/index.html
> >
> >jisp is part of the dependencies. :-(
> >See:
> >http://jakarta.apache.org/turbine/jcs/dependencies.html
> >
> >Best Regards,
> >
> >Antonio Gallardo
>
> I wrote that version 3.0.0 is GPLed.
>
> If you read
> http://www.coyotegulch.com/jisp/license> _policy.html
> carefully,
> you will notice that it says
> "Older Versions
> Older versions of Jisp use different licenses; those licenses
> only apply to
> Jisp version 2.6 and earlier. Jisp 3.0.0 is licensed under
> new terms, and
> old terms from the previous version may not be applied to
> Jisp version
> 3.0.0 or later."
>
> IMHO as long as the old jisp (v2.6 or lower) is used, nothing
> needs to
> change. No updates anymore, though.
That's right for the near future but this also means we don't get any
upgrades/patches and this is IMO no good thing. Hence I think that we
should find a replacement.
--
Reinhard
RE: Jisp 3.0 moved to GPL licence
Posted by Gunnar Brand <g....@interface-business.de>.
Am 05:39 20.02.2004 -0600 schrieb Antonio Gallardo:
>Carsten Ziegeler dijo:
> > What about JCS?
> >
> > http://jakarta.apache.org/turbine/jcs/index.html
>
>jisp is part of the dependencies. :-(
>See:
>http://jakarta.apache.org/turbine/jcs/dependencies.html
>
>Best Regards,
>
>Antonio Gallardo
I wrote that version 3.0.0 is GPLed.
If you read http://www.coyotegulch.com/jisp/license_policy.html carefully,
you will notice that it says
"Older Versions
Older versions of Jisp use different licenses; those licenses only apply to
Jisp version 2.6 and earlier. Jisp 3.0.0 is licensed under new terms, and
old terms from the previous version may not be applied to Jisp version
3.0.0 or later."
IMHO as long as the old jisp (v2.6 or lower) is used, nothing needs to
change. No updates anymore, though.
gunnar
--
G. Brand - interface:projects GmbH
Tolkewitzer Strasse 49
D-01277 Dresden
mail: g.brand@interface-projects.de
tel: ++49-351-3 18 09 - 41
Ein Unternehmen der interface:business-Gruppe
Re: Jisp 3.0 moved to GPL licence
Posted by Ugo Cei <u....@cbim.it>.
Carsten Ziegeler wrote:
> What about JCS?
>
> http://jakarta.apache.org/turbine/jcs/index.html
>
> Carsten
I know that Hibernate moved away from JCS because of some bugs, but I
cannot recall exactly what problems it had.
Another candidate might be OSCache [1].
Ugo
[1]: <http://www.opensymphony.com/oscache/>
RE: Jisp 3.0 moved to GPL licence
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
What about JCS?
http://jakarta.apache.org/turbine/jcs/index.html
Carsten
> -----Original Message-----
> From: Reinhard Poetz [mailto:reinhard@apache.org]
> Sent: Friday, February 20, 2004 11:53 AM
> To: dev@cocoon.apache.org
> Subject: Jisp 3.0 moved to GPL licence
>
>
> > Am 14:01 10.02.2004 -0500 schrieb Steve Krulewitz:
> > >Does anyone know what happened to the jisp website? The old URL
> > >http://www.coyotegulch.com/jisp/index.html sends you to an
> > invalid link.
> >
> > It's back up now: http://www.coyotegulch.com/jisp/ I never
> went there
> > before it went down, but it now has a version 3.0.0. That version
> > isn't under the old license anymore but GPLed (or commercial for
> > 2500$).
> > Old versions I can't find there..
> >
> > gunnar
> >
> > ps: sorry if you get this mail twice, steve. small mistake by me.
> >
> > --
> > G. Brand - interface:projects GmbH
>
>
> As our store depends on Jisp - what does this mean for us? IMO we have
> to look for a replacement. Any ideas/hints?
>
> --
> Reinhard
>
>
Re: Jisp 3.0 moved to GPL licence
Posted by Steven Noels <st...@outerthought.org>.
On 20 Feb 2004, at 13:36, Steven Noels wrote:
> I will contact them.
Just done so. As I wanted to give Scott the possibility to vent about
this issue in private, I only copied the PMC list. Hope you understand.
Of course, we'll get back with the conclusion on the dev list as well.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Jisp 3.0 moved to GPL licence
Posted by Steven Noels <st...@outerthought.org>.
On 20 Feb 2004, at 13:25, Bertrand Delacretaz wrote:
> Hmm..I'm not too excited by http://www.coyotegulch.com/jisp/index.html
> mentioning "the Apache project" as a reference user of their software
> and at the same time changing the license in a way that will prevent
> us from using Jisp in the future.
I will contact them.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Jisp 3.0 moved to GPL licence
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Vendredi, 20 fév 2004, à 11:52 Europe/Zurich, Reinhard Poetz a écrit
:
> ...As our store depends on Jisp - what does this mean for us? IMO we
> have
> to look for a replacement. Any ideas/hints?
Hmm..I'm not too excited by http://www.coyotegulch.com/jisp/index.html
mentioning "the Apache project" as a reference user of their software
and at the same time changing the license in a way that will prevent us
from using Jisp in the future.
Maybe it is still possible for them change their mind about this?
Cocoon can certainly be a good proof of Jisp's quality, if I were them
I'd try to do something to make it possible for the ASF to continue
using Jisp.
Anyone from CoyoteGulch listening here?
-Bertrand