cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [status & RT] design challenges
Date Fri, 05 Apr 2002 21:14:47 GMT
Stefano Mazzocchi wrote:

>Hi people,
>there are a few design challenges that are on the table and I think it's
>time for us to attack them in full detail. They are:
> 1) flow-based programming 
> 2) user-level modularization
> 3) pipeline symmetry
>                                   - o -
>I have the feeling that these concepts are so important that cannot be
>handled separately but should be described into a coherent architecture.
>'flow-based programming' starts from the evidence that stateful web
>applications are poorly described declaratively.
>My personal view is that Cocoon describes a very nice and elegant
>component model, but introduces a declarative approach for component
>control. This is not enough.
>I think that Ovidiu's work on Schecon can bring balance to this picture
>by making it possible to *choose* between a declarative approach for
>pipeline control (using sitemaps) or a procedural approach for pipeline
>control (using flowmaps).
>The ability to nest one into the other allows something that is not
>possible today: since there are frameworks that are web-app focused and
>frameworks that are publishing-focues. Cocoon will do both *together*
>with seamless integration and elegant coherence.
>                                   - o -
>User-level modularization will be handled by Cocoon Blocks and with
>blocks collections that can be aggregated to create fully functional
>modules (just like SAR and BAR for Phoenix)
>                                   - o -
>The third big question is about pipeline symmetry.
>There are several issues that keep on coming up about the pipeline
>architecture and its component model:
> 1) serializers don't have full access to the component environment and
>some want this to be changed

The major need is to be able to access the SourceResolver. I haven't 
seen any good use case where a Serializer needs to access something else 
in the environment. So what about a "SourceResolvable" interface handled 
by CocoonComponentManager ?

public interface SourceResolvable {
  void setSourceResolver(SourceResolver resolver),

One more use case for this need : I have pending on my HD a Batik 
ProtocolHandler that allows any Cocoon source to be used in Batik's URL 
handling system. This allows to insert bitmaps stored in Blobs (using 
the BlobSource in scratchpad) in SVG drawings. The only thing that's 
needed is the SourceResolver. Nothing else.

>  2) selectors don't have access to the pipeline content and some want
>this to be changed
> 3) serializers are always associated with the client output stream, so
>they can't be used with other streams

Add a "dest" attribute on a <map:serialize> that resolves to a 
WriteableSource and you're done !

>  4) if #3 is implemented there is the need for a multiplexor that
>divides the pipeline and acts parallely from the aggregator.

Yep. BTW, have you seen Transmorpher at 
? They mention Cocoon as one of they inspiration sources. Could the 
opposite happen ?

>                                    - o -
>All these requests have valid and useful functional needs. The question,
>at this point, is not about the functional needs they express, but about
>which is the "best" design decision that can be made to make the
>required functionality possible.
>"best" is admittedly a personal feeling, but we should try to:
> 1) reduce the impact on back incompatibility to a minimum
> 2) reduce the creation of 'multipaths' to a minimum (a 'multipath' is
>created when there is "more than one way to do it". It's up to *us* to
>identify the best way to do something, it's not the user's concern!)
> 3) reduce the creation of new components to a minimum (the more stuff
>the user has to know, the harder it is to start, the harder it is to
>reduce 'multipaths')
>With this in mind, I believe that:
> 1) serializers shouldn't be considered as normal components, but just a
>adaptors for the outside world. They must not need access to information
>outside the pipeline. Everything that needs to *augment* the pipeline
>should be a Transformer.
> 2) pipe-aware selectors and mutliplexed pipelines have separate
>concerns, so a decision on one doesn't impact the decision on the other
>Now, let's try to give a final result at least on the pipe-aware
> a) I still believe that selectors shouldn't be pipeline aware.
>Let me draw a parallel here: let us consider pipelines that transport
>liquids (water, oil, etc...) and let us suppose that we have to 'route'
>the flow of those liquids.
>So we have things like
>           /
>          /
>  ------[*]---
>          \
>           \
>where the central valve [*] acts as a selector. Let us suppose that we
>also have a liquid source (a generator, so to speak), and we might also
>have 'T' pipes that 'augment' or 'transform' the liquid flow.
>                       /
>                      /
> [o]>-----[+]-------[*]----
>           |          \
>           |           \
>Now, let us suppose that the valve needs to know something "about" the
>liquid to deviate it's flow (for example, if the liquid pressure is too
>high, the valve has to switch exiting pipe)
>There are several ways to do this:
> 1) the valve has built-in a sensor about liquid pressure
> 2) the valve gets coupled with an external sensor
>Both solutions work, but the second is more modular and less expensive:
>you don't need to have a number of valves each aware of something
>Unfortunately, Solution 2) requires communication between the sensor
>(transformer) and the valve (selector).
>This can be performed:
> 1) inside the pipe
> 2) outside the pipe
>Pipe-aware selection works with #1 and in our example, it would be like
>adding a special property to the liquid flowing into the pipeline (say,
>coloring the liquid, or altering its pH) and having one standardized
>meter built into the valve.
>Or, outside the pipe, means transmitting the information in some other
>way (in real life, there is an electrical signal between the sensor and
>the actuator).
>My impression is that pipe-aware selection is 'forcing' metadata to pass
>'thru' the pipeline while it doesn't really make sense to do so.
>So, IMO, there must be some transformers that obtain the required
>selection information from the pipeline, place it somewhere else
>(probably someplace in the object model) and have the selectors look at
>those 'parallel signals' without having to mess with the pipeline.
>So, I restate my -1 on pipe-aware selection and I propose the creation
>of a 'parallel transport layer' between components that is based on
>objects and not SAX events.
>NOTE: this has nothing to do with implementation issues even if, at the
>end, will probably result in better performance because 'early
>optimization is the root of evil' but 'using antipatterns is even
>worse!' :)
>Fire at will.

Hey, not fire : discuss ;)

I'm not sure the analogy with pipes and valve is really appropriate : in 
the above, the liquid pipeline is changed *while* the liquid is flowing, 
meaning the liquid that has flown _before_ the sensor acted on the valve 
doesn't go through the same pipes than the liquid flowing _after_ the 
sensor acted.

This doesn't fit with the goal underlying pipe-aware selectors : their 
goal (correct me if I'm wrong) is to determine fully the pipeline by 
examining its content at a given stage, before anything gets out of it. 
Going back to the liquid analogy, it's like having a capacity 
(reservoir) placed before the valve where different pipes can be chosen. 
Once enough liquid has flown in the capacity to give us the information 
we need to determine the route in the pipes, then we can position the 
valve and open it.

The main problem with Daniel's contribution is that the whole document 
has to be buffered in a DOM before any decision can be taken : it's like 
going back to the slow times of Cocoon 1. But we could imagine some 
smarter implementations based on partial buffering using compiled XML 
and things like STX ( to avoid 
complete buffering.

About separating the sensor and the valve by transmitting the 
information outside the pipeline, I consider it as introducing a 
"pipe-aware action". The main difference with a selector is that an 
action doesn't necessarily change the pipe flow, and can do anything it 
wants with the environment, including setting values used later by a 
selector. So in this sense, this fits the need and is more versatile.

Also, since a pipe-aware action would have only one input and one ouput, 
it would be easier to implement than a selector that has several 
outputs, meaning we can have more easily some smart-buffering 
implementations like mentioned above.

What do you think ?


Sylvain Wallez
 Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message