Re: Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]
Alan wrote:
* Daniel Fagerstrom [EMAIL PROTECTED] [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
Re: Jisp 3.0 moved to GPL licence
* Geoff Howard [EMAIL PROTECTED] [2004-02-22 18:47]: Alan wrote: * Upayavira [EMAIL PROTECTED] [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 / [EMAIL PROTECTED] / http://engrm.com/ aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]
Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]
[changing subject...] Reinhard Poetz wrote: From: Alan * Geoff Howard [EMAIL PROTECTED] [2004-02-22 18:47]: Alan wrote: * Upayavira [EMAIL PROTECTED] [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: Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]
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
Re: Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]
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
Re: Jisp 3.0 moved to GPL licence
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 smime.p7s Description: S/MIME cryptographic signature
Re: Jisp 3.0 moved to GPL licence
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
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. Carsten
RE: Jisp 3.0 moved to GPL licence
-Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Sunday, February 22, 2004 4:06 PM To: [EMAIL PROTECTED] 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
Alan wrote: * Antonio Gallardo [EMAIL PROTECTED] [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
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-devm=107700015102265w=4 [2] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107711295731173w=4 [3] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107712768202660w=4 [4] complete thread: http://marc.theaimsgroup.com/?t=10769599726r=1w=4
Re: Jisp 3.0 moved to GPL licence
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-devm=107700015102265w=4 [2] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107711295731173w=4 [3] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107712768202660w=4 [4] complete thread: http://marc.theaimsgroup.com/?t=10769599726r=1w=4
Re: Jisp 3.0 moved to GPL licence
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
What about JCS? http://jakarta.apache.org/turbine/jcs/index.html Carsten -Original Message- From: Reinhard Poetz [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 11:53 AM To: [EMAIL PROTECTED] 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
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
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
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
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: [EMAIL PROTECTED] tel:++49-351-3 18 09 - 41 Ein Unternehmen der interface:business-Gruppe
Re: Jisp 3.0 moved to GPL licence
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
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
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: [EMAIL PROTECTED] tel:++49-351-3 18 09 - 41 Ein Unternehmen der interface:business-Gruppe
RE: Jisp 3.0 moved to GPL licence
From: Gunnar Brand [mailto:[EMAIL PROTECTED] 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
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
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
Re: Jisp 3.0 moved to GPL licence
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Jisp 3.0 moved to GPL licence
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
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
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
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Jisp 3.0 moved to GPL licence
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. smime.p7s Description: S/MIME Cryptographic Signature
Re: Jisp 3.0 moved to GPL licence
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Jisp 3.0 moved to GPL licence
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. smime.p7s Description: S/MIME Cryptographic Signature
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. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Xindice filer, Re: Jisp 3.0 moved to GPL licence
Upayavira wrote: Antonio Gallardo wrote: Maybe this is a crazy idea but: Is posible to replace jisp with Apache Xindice? Mainly because I have concerns for another ugly move (as jisp did) if we choose a solution from a 3rd party again. If we use Apache Xindice I think this cannot happen again. Could do. How efficient is XIndice? It would need to be pretty efficient on binary data too, as that is our primary use case. Xindice has a Filer abstraction, and there is BTreeFiler implementation. It stores binary objects under an arbitrary binary key, and keys are organized into the BTree for fast store/retrieval. See test for filer here: http://cvs.apache.org/viewcvs.cgi/xml-xindice/java/tests/src/org/apache/xindice/core/filer/FilerTestBase.java?view=auto Filer uses several RandomAccessFile descriptors to provide concurrent reads / writes to the file. Vadim
Re: Xindice filer, Re: Jisp 3.0 moved to GPL licence
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
Re: Jisp 3.0 moved to GPL licence
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
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 3:55 PM To: [EMAIL PROTECTED] 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: Xindice filer, Re: Jisp 3.0 moved to GPL licence
Geoff Howard wrote: Vadim Gritsenko wrote: Upayavira wrote: Antonio Gallardo wrote: Maybe this is a crazy idea but: Is posible to replace jisp with Apache Xindice? Mainly because I have concerns for another ugly move (as jisp did) if we choose a solution from a 3rd party again. If we use Apache Xindice I think this cannot happen again. Could do. How efficient is XIndice? It would need to be pretty efficient on binary data too, as that is our primary use case. Xindice has a Filer abstraction, and there is BTreeFiler implementation. It stores binary objects under an arbitrary binary key, and keys are organized into the BTree for fast store/retrieval. See test for filer here: http://cvs.apache.org/viewcvs.cgi/xml-xindice/java/tests/src/org/apache/xindice/core/filer/FilerTestBase.java?view=auto Filer uses several RandomAccessFile descriptors to provide concurrent reads / writes to the file. Does that answer mean you think a XIndice persistent store implementation would be a good fit? As you're involved heavily in both projects, you'd be the best to comment probably... It would work. Take a look at the linked class, as well as at Filer interface. What's your opinion? Vadim
Re: Xindice filer, Re: Jisp 3.0 moved to GPL licence
Vadim Gritsenko wrote: 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
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Geoff Howard wrote: Vadim Gritsenko wrote: Upayavira wrote: Antonio Gallardo wrote: Maybe this is a crazy idea but: Is posible to replace jisp with Apache Xindice? Mainly because I have concerns for another ugly move (as jisp did) if we choose a solution from a 3rd party again. If we use Apache Xindice I think this cannot happen again. Could do. How efficient is XIndice? It would need to be pretty efficient on binary data too, as that is our primary use case. Xindice has a Filer abstraction, and there is BTreeFiler implementation. It stores binary objects under an arbitrary binary key, and keys are organized into the BTree for fast store/retrieval. See test for filer here: http://cvs.apache.org/viewcvs.cgi/xml- xindice/java/tests/src/org/apac he/xindice/core/filer/FilerTestBase.java?view=auto Filer uses several RandomAccessFile descriptors to provide concurrent reads / writes to the file. Does that answer mean you think a XIndice persistent store implementation would be a good fit? As you're involved heavily in both projects, you'd be the best to comment probably... It would work. Take a look at the linked class, as well as at Filer interface. What's your opinion? Using XMLDB would mean another ~500KB more in Cocoon core ... :-( -- Reinhard
Re: Xindice filer, Re: Jisp 3.0 moved to GPL licence
Upayavira wrote: Vadim Gritsenko wrote: Geoff Howard wrote: Vadim Gritsenko wrote: Xindice has a Filer abstraction, and there is BTreeFiler implementation. It stores binary objects under an arbitrary binary key, and keys are organized into the BTree for fast store/retrieval. See test for filer here: http://cvs.apache.org/viewcvs.cgi/xml-xindice/java/tests/src/org/apache/xindice/core/filer/FilerTestBase.java?view=auto Filer uses several RandomAccessFile descriptors to provide concurrent reads / writes to the file. Does that answer mean you think a XIndice persistent store implementation would be a good fit? As you're involved heavily in both projects, you'd be the best to comment probably... It would work. Take a look at the linked class, as well as at Filer interface. What's your opinion? That's what I think. It would work. The issue in my mind is more to do with performance. Could it compete with jisp? Do you have any thoughts there Vadim? Well, this I don't know (and I never looked into Jisp source code - so can't comment on its workings). Do you want to test it? What I know is that filer is ~ 100kb of Java source code, so it would be easier to find / fix bugs, if any. In compiled form it will be even less. To address Reinhard's concern, it could be packaged into separate jar, of Jisp size or so. So, if Jisp sticks to GPL, we still would have several options - from JCS to Xindice Filer. PS What's JCS size / performance / etc? Vadim
RE: Xindice filer, Re: Jisp 3.0 moved to GPL licence
From: Vadim Gritsenko 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
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
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: Jisp 3.0 moved to GPL licence
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
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
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
Reinhard Poetz dijo: -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 3:55 PM To: [EMAIL PROTECTED] 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
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
