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: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101802546717014&w=2
> '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 and > 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 and > 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 +1 > 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!) +1 > 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 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. +1 <snip/> -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
