cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <>
Subject RE: [status & RT] design challenges
Date Sun, 07 Apr 2002 16:41:45 GMT
I don't profess to be meritorious, relevant, or knowledgeable enough to
reply to this but a couple of things you said concern me so here goes..
(mostly on serializer interactions).  I've responded to only those
things that I have a direct interest in, have direct knowledge of or
would like clarification on.  All other things have been ommitted. 
Those reading this should refer to the original message for context: 

> 'flow-based programming' starts from the evidence that stateful web
> applications are poorly described declaratively.

Maybe I'm not understanding correctly...

I still think a declarative approach can be prescribed.  There are
plenty of non-declarative approaches out there, and we don't really need
one more.  One should differentiate Cocoon is a "next-generation"
approach.  Don't dirty it with a kludge.  Meaning don't add something
that is to Cocoon what JSP is to Object Oriented Programming and Java.

> 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.

+1 enhancing it.  -1 on breaking the paradigm.  

> The ability to nest one into the other allows something that is not
> possible today: since there are frameworks that are web-app focused
> frameworks that are publishing-focues. Cocoon will do both *together*
> with seamless integration and elegant coherence.

That sounds good.

> 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
> some want this to be changed

I'm not sure this is a good idea.  Perhaps what is needed is something
besides the serializer.  It would seem to me that the transformer should
serve some of the functions this statement seems to suggest.  Wouldn't
IoC dictate that the relevant environment be pushed into the serializer?
> 3) serializers are always associated with the client output stream, so
> they can't be used with other streams

I'm not sure this is bad.  I think the *other thing* should handle what
this statement seems to suggest.  (For instance serializing output into
a stream somewhere else?).  I think perhaps adding a "destination"
configuration to a serializer and allowing multiple serializers to act
on one pipleline might be better.  Only one serializer per destination,
the state is preserved when entering into each serializer.

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

+1 (see above) - it should handle the parallel nature of it but the
"destination" of the stream is a separate concern. 

> 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')

+0 - there are situations where complex issues require an understanding
of complexity or where one more component is easier then one big
component.  Obviously entropy + complexity is to be avoided where
feasible to do so without increasing it elsewhere as a consequence.  I
take this to be a constant.

> 1) serializers shouldn't be considered as normal components, but just
> adaptors for the outside world. They must not need access to
> outside the pipeline. Everything that needs to *augment* the pipeline
> should be a Transformer.



-- - port of Excel/Word/OLE 2 Compound
                            format to java 
			- fix java generics!
The avalanche has already started. It is too late for the pebbles to
-Ambassador Kosh

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

View raw message