Thanks for pointing it out again.
Giacomo
On Wed, 3 Apr 2002, Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
> > Yeah, I know Stefano doesn't like that, but so many people feel the need
> > for it... So Stefano, if you don't like that, please give us a cool
> > explanation like the one you
Sylvain Wallez wrote:
> Yeah, I know Stefano doesn't like that, but so many people feel the need
> for it... So Stefano, if you don't like that, please give us a cool
> explanation like the one you gave for "views from last label". IIRC this
> has to do with cacheability, but CachingStreamPipelin
Carsten Ziegeler wrote:
>
> Hi,
>
> just a short and simple RT for today:
>
> What do you all think about merging the stream and the event pipeline
> into one single interface/object?
> This would make the system less complex and reduce lookups per request
> as well.
I agree, +1. I've been bug
> >Hi,
> >
> >just a short and simple RT for today:
> >
> >What do you all think about merging the stream and the event pipeline
> >into one single interface/object?
> >This would make the system less complex and reduce lookups per request
> >as well.
> >
>
> +1.
+1
>
> I'd like also we take a f
On Wed, 3 Apr 2002, Carsten Ziegeler wrote:
>
> Sylvain Wallez wrote:
> >
> > I'd like also we take a formal decision about allowing a Serializer to
> > be a SitemapModelComponent. This comes regularly on the table, and there
> > have been several uses cases showing the need for it, mainly to acc
Sylvain Wallez wrote:
>
>
> Also, Carsten, can you please explain how a SourceResolver fetched from
> a CM will handle the per-request data used to resolve sources, i.e. the
> Environment and Processor used by SitemapSource and the context prefix
> set by sitemap mounts ? Will this be based on R
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>>I'd like also we take a formal decision about allowing a Serializer to
>>be a SitemapModelComponent. This comes regularly on the table, and there
>>have been several uses cases showing the need for it, mainly to access
>>the SourceResolver. An
Sylvain Wallez wrote:
>
> I'd like also we take a formal decision about allowing a Serializer to
> be a SitemapModelComponent. This comes regularly on the table, and there
> have been several uses cases showing the need for it, mainly to access
> the SourceResolver. And I've got a new use cas
streams.
However -> kool Carsten.
~Gerhard
"Sorry, but my karma just ran over your dogma."
>-Original Message-
>From: Davanum Srinivas [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, April 02, 2002 6:26 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [VOTE] (was: [R
Three +1 from me too.
Please post the new interface for the new pipeline so I can think of
how to modify the code in Schecoon accordingly.
Thanks,
Ovidiu
On Tue, 2 Apr 2002 08:26:08 -0800 (PST), Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> +1 for (merging the stream and the event pipeline).
>
+1 for (merging the stream and the event pipeline).
+1 for (Allow a Serializer to be a SitemapModelComponent. ***I REALLY NEED THIS***)
+1 for (Configurable pipelines)
Thanks,
dims
--- Sylvain Wallez <[EMAIL PROTECTED]> wrote:
> Carsten Ziegeler wrote:
>
> >Hi,
> >
> >just a short and simple RT
Carsten Ziegeler wrote:
>Hi,
>
>just a short and simple RT for today:
>
>What do you all think about merging the stream and the event pipeline
>into one single interface/object?
>This would make the system less complex and reduce lookups per request
>as well.
>
+1.
I'd like also we take a forma
From: "Carsten Ziegeler" <[EMAIL PROTECTED]>
> What do you all think about merging the stream and the event pipeline
> into one single interface/object?
You mean something like:
{
String ROLE = "org.apache.cocoon.components.pipeline.Pipeline";
boolean process(...)
void setGenerato
Hi,
just a short and simple RT for today:
What do you all think about merging the stream and the event pipeline
into one single interface/object?
This would make the system less complex and reduce lookups per request
as well.
The splitting into those two objects was done to help implementing th
14 matches
Mail list logo
