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
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
4) if #3 is implemented there is the need for a multiplexor that
divides the pipeline and acts parallely from the aggregator.
- 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
selection:
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
different.
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.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
