Gerhard Froehlich wrote:
>>-Original Message-
>>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>>Sent: Saturday, December 01, 2001 2:50 PM
>>To: [EMAIL PROTECTED]
>>Subject: Re: Cocoon 2.0 Scalability Disappointment
>>
>>
>>Gerhard Froehlich wrote:
>>
>>
-Original Message-
>>
>-Original Message-
>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>Sent: Saturday, December 01, 2001 2:50 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Cocoon 2.0 Scalability Disappointment
>
>
>Gerhard Froehlich wrote:
>
>>>-Original Message-
>>>From: Chris Finn [mailto:[EMAIL PROTEC
giacomo wrote:
> On Fri, 30 Nov 2001, Stefano Mazzocchi wrote:
>
>
>>giacomo wrote:
>>
>>
In software terminology, an accumulator is normally called a "store",
"archive", "cabinet", "safe" and so on with terms that give you an idea
of "something" that allows you to place information
Gerhard Froehlich wrote:
>>-Original Message-
>>From: Chris Finn [mailto:[EMAIL PROTECTED]]
>>
> As I did load tests with the RC1 I made the same experience.
> With the help of OptimizeIt (http://www.vmgear.com/) I discovered
> that most resource is burning the ClassLoader and stuff.
> Se
Stefano Mazzocchi wrote:
>Michael Hartle wrote:
>
>>I guess XUpdate is depending on input as almost every other process of
>>standardization; what about actively participating on the evolution of
>>XUpdate instead of distant, probably unheard evaluation ? I think that
>>Stefanos view should be po
Stefano Mazzocchi wrote:
>Back to the Cocoon URI-space problem. The URI
>
> http://xml.apache.org/cocoon/installing
>
>"identifies" information about "installing Apache Cocoon" and "locates"
>the latest version of this document.
>
>If we found valuable (but I do not, having CVS) to create contrac
John Morrison wrote:
>
> So we should have...
>
> http://xml.apache.org/cocoon/1/
> http://xml.apache.org/cocoon/2/
>
> and
>
> http://xml.apache.org/cocoon/ -> http://xml.apache.cocoon/2/
>
> Yes?
No. Cocoon URIs must be version agnostic, they must convey only semantic
meaning.
--
Stefano
Michael Hartle wrote:
>
> Jeremy Quinn wrote:
>
> >The XUpdate language (however flawed) looks to me designed primarily for
> >inserting stuff into existing fragments, it is not expressive in terms of
> >adding new documents to collections, or files to filesystems.
> >
> >We need to be able to d
Jeremy Quinn wrote:
> >I'll try to come up with something because, as it stands, I would be
> >very -1 in basing Cocoon XML persistant capabilities on such a spec.
>
> fair enough . (and I am NOT arguing FOR XUpdate here .)
>
> However, what you have subsequently written (your "[RT] Dre
On Sat, 01 Dec 2001 14:54:51 +0100, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> > What I was looking at were continuations in functional languages like
> > Scheme.
>
> Uh, gosh, I find myself with no info on this... how is that possible? :)
You ought to fill in the hole fairly quick ;-) It'
At 1:09 pm +0100 1/12/01, Michael Hartle wrote:
>Jeremy Quinn wrote:
>
>>The XUpdate language (however flawed) looks to me designed primarily for
>>inserting stuff into existing fragments, it is not expressive in terms of
>>adding new documents to collections, or files to filesystems.
>>
>>We need
>-Original Message-
>From: Chris Finn [mailto:[EMAIL PROTECTED]]
>
>--- Gerhard Froehlich <[EMAIL PROTECTED]> wrote:
>> 6) Look at the store parameters
>> (store,store-janitor,...) in the
>> cocoon.xconf file and customize them -as recommended
>> in the comments- for
>> your testing mach
On Fri, 30 Nov 2001, Gianugo Rabellino wrote:
> Stefano Mazzocchi wrote:
>
> > 3) they don't use a transparent proxy on top so the Cocoon cache is
> > continously stressed.
>
>
> If they are using XSP (or anyway are dynamically generating data) a
> transparent proxy won't help a lot: it will help
On Fri, 30 Nov 2001, Stefano Mazzocchi wrote:
> giacomo wrote:
>
> > > In software terminology, an accumulator is normally called a "store",
> > > "archive", "cabinet", "safe" and so on with terms that give you an idea
> > > of "something" that allows you to place information that will
> > > pers
So we should have...
http://xml.apache.org/cocoon/1/
http://xml.apache.org/cocoon/2/
and
http://xml.apache.org/cocoon/ -> http://xml.apache.cocoon/2/
Yes?
> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, 01 December 2001 2:34 pm
> To: [EMAIL
If incremental processing is disabled (the default) Xalan fires the SAX
events after all transformations have been done.
Under heavy load this can cause great memory usage I guess.
I'm not sure about that. Just a hint.
JOERN
-Ursprungliche Nachricht-
Von: Stefano Mazzocchi [mailto:[EMAIL
Jeff Turner wrote:
> Say I write a HTML page, "How to install Cocoon 2 with FooBar
> extensions". I want to reference the content currently at:
>
> http://xml.apache.org/cocoon/installing/
>
> But I can't, because when Cocoon 2.x or 3 comes out, it won't be the
> same content I intended to refe
Ovidiu Predescu wrote:
>
> This is very interesting, in the past few weeks I was investigating
> alternative approaches to FSM too!
This is getting interesting. Talking about distributed IQ :)
> What I was looking at were continuations in functional languages like
> Scheme.
Uh, gosh, I find m
Sam Ruby wrote:
>
> Stefano Mazzocchi wrote:
> >
> > 1) it should be possible to see it as a single persistent tree of DOM
> nodes.
> >
> > 2) it should contain node-level version information and should provide
> > a tagging concept (here, think as a parallel between CVS files and these
> > DOM n
Paul Brown wrote:
>
> Stefano --
>
> Are you using Xalan J2.2.Dx within Cocoon? If so, that may account for it.
> Depending on the application, we've observed SIGNIFICANT performance
> problems with Xalan J2.2.Dx, especially where a transition DOM<->DTM occurs.
I'm not the one who made the tes
Berin Loritsch wrote:
> > Sounds great to me. Are you volunteering? ;-)
>
> The time, the time!
:)
> Seriously, I can do it as it is a fairly trivial component. Question, do you
> want a run-time system to be able to dynamically add mime-types to the system?
hmmm, don't know, but I would aut
I now made a clean rebuild of the cocoon.war
and tried on a different machine with a different
servlet engine (resin).
Different exception but still cocoon does not
come up. (looks always like something goes wrong
inside the Avalon Framework DefaultConfigurationBuilder)
Can anyone confirm this pr
>-Original Message-
>From: Chris Finn [mailto:[EMAIL PROTECTED]]
>
>--- Gerhard Froehlich <[EMAIL PROTECTED]> wrote:
>> 6) Look at the store parameters
>> (store,store-janitor,...) in the
>> cocoon.xconf file and customize them -as recommended
>> in the comments- for
>> your testing mach
Jeremy Quinn wrote:
>The XUpdate language (however flawed) looks to me designed primarily for
>inserting stuff into existing fragments, it is not expressive in terms of
>adding new documents to collections, or files to filesystems.
>
>We need to be able to do both!!!
>
>That said, yes I am very i
At 7:38 pm +0100 30/11/01, Stefano Mazzocchi wrote:
>I've just reread the XUpdate spec. Here are my quick comments:
>
>1) no namespace support. I mean, there is no namespace concept taken
>into consideration in the spec.
>
>This would, *alone*, make it virtually useless for any serious XML
>storag
25 matches
Mail list logo
