cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <steven.d...@indoqa.com>
Subject Re: [C3] Pipeline component event types
Date Tue, 13 Jan 2009 20:05:01 GMT
Carsten Ziegeler schrieb:
> Steven Dolg wrote:
>   
>> Carsten Ziegeler schrieb:
>>     
>>> Wouldn't it be better/easier to have a sax pipeline, a dom pipeline, a
>>> stax pipeline, perhaps sharing a common interface?
>>>   
>>>       
>> From my point of view:
>> Currently the user must know which components he needs (as in "I want to
>> process XML and I'd like to do it with StAX").
>> As soon as he know this, he just selects the components (either existing
>> or created) but them in *any* pipeline (caching/noncaching/etc.)
>>     
> But the user needs to choose the same xml transportation for all
> components in the pipeline, being it directly or through wrappers.
>   
I don't think  I understand what you mean by "same xml transportation".
Currently creating and executing a pipeline looks like:

Pipeline pipeline = ...;
pipeline.add(new StAXGenerator(inputURL));
pipeline.add(new StAXTransformer(myParameter));
pipeline.add(new StAXSerializer();

pipeline.setup(outputStream);
pipeline.execute();

It is the same when using SAX (except different components, of course) 
or when processing any other type of data (I think I should really go 
and build that Imaging module...).

Again I have the feeling that some concepts that Cocoon has for years 
now (Pipelines look like Generator -> Transformer -> Serializer; make 
sure the sitemap makes sense; know what the components actually do) are 
all of a sudden too complicated for any user to apply them safely 
without reading the source code.
But that may be just me...
>   
>> If there were multiple, content-specific Pipelines he still needs to
>> know which components, but also which type of Pipeline.
>> If he feels the need to change to SAX (so a switch in the "event type" -
>> IMO a sub-optimal term, since not every component actually passes nice
>> events like StAX does) he also needs to change the Pipeline.
>> This may seem easy now, but imagine a larger system. Changing the
>> pipeline type can be challenging there.
>>     
> >From what I understand so far in this discussion this simple switching
> does not work (or is not intended to be implemented - which is fine for
> me).
This simple switching of components works right now!
While creating the StAX components we often exchanged the components 
(again all of them, not individual ones - SAX and StAX are not 
compatible without adapters)
to compare the results from SAX and StAX.

>  So besides from switching the pipeline implementation you have to
> switch all components or at least add matching wrappers around them.
>   
I'm not proposing content-specific pipeline implementations.

IMO demanding that the user also selects the correct pipeline type for 
his choice of components - that need to be compatible with each other 
*and* the pipeline - is actually more than just demanding that he 
chooses components that are compatible with each other and guaranteeing 
that any (correctly implemented) pipeline will do the job.

Since this is about making it easier for the user, I think content 
specific pipelines actually cause the opposite effect, because it adds 
another element to be considered.

On top of that it also makes introducing new content types harder since 
one has to provide a pipeline implemementation (and possibly interface), 
too.
The components need to communicate with each other nonetheless. The 
additional "Are you compatible with me?" check is fairly easy compared 
to that (for StAX that are 3 lines of code in one abstract base class).

Being able to use the same Pipeline implementations (even the rather 
sophisticated asynchronous caching pipeline) has saved us probably days 
of work and that compatibility check took no more than 5 minutes once 
the interfaces for the components (which we needed anyway) were defined.
>   
>> And what about automatically generated pipelines (e.g. the sitemap).
>> This will be so much harder as you have to collect and analyze all
>> components first before you can actually build the pipeline to use.
>>     
> I think you have to do this anyway - as not all components fit together.
>   
Currently we have no need to select the pipeline specifically for the 
components to be used (in fact the sitemap builds the pipeline before 
even knowing the components).
If the components are really not compatible this will be detected before 
the pipeline is actually executed (in the setup phase).
>   
>> Defining a common interface for different pipeline types does not really
>> change this.
>> If the common interface is sufficient for handling and operating the
>> pipeline they are exchangable (from the callers point of view) and
>> provide the same environment we have now.
>> If the common interface is not sufficient for handling and operating the
>> pipeline it is merely a marker interface and it probably wouldn't make
>> much difference. (Although it is still useful for declaring parameter
>> types, etc.)
>>
>>
>> I may be biased here ;-) but I have yet to see the benefits of different
>> pipeline types...
>>     
> :) I have the same feeling for the opposite...if I can't just mix dom
> with sax and maybe stax, then why following this generic approach?
>
> Hmm, maybe generics could help?
> So we have something like:
> public interface Pipeline<T extends PipelineComponent>
>
> and have sub interfaces for PipelineComponent for sax, dom, stax?
>   
> This ensures to have a single implementation but gives compiler time checks.
>   
Well that would be nice of course.
But so far not working solution/prototype has been made available (or 
did I simply miss it?).

And those that have merely scratch surface IMO.
There are still things like component order: Generator, Generator, 
Transformer, Serializer, Generator is clearly not a valid pipeline, even 
if all components are actually using the same technology.

> Carsten
>   


Mime
View raw message