[For those of you who didn't study elettronic, MOSFET transistors have
sources, drains and gates. Sources generate electrons, drains consume
them and gates control the flow]
The original idea of a pipeline was
g -> t* -> s
you all know this very well.
Then I realized that the same pipelines shared the same properties, so I
came up with the notion of resource views, which required a way to 'get
out' of the normal pipeline flow. This was implemented with 'views' and
'labels'
g -> t* -> s
[label] -> t* -> s
so that we could ask for a specific 'view' and do something like
g -> t -> t* -> s [normal view]
|
+ -> t* -> s [another view]
Then we wanted to merge different pipelines with 'aggregation', so we
needed a way to do something like
g -> t* -> A -> t* -> s
^
g -> t* ---+
this created the notion of 'internal pipelines', those pipelines who
don't need a serializer because their sax events are aggregated
directly.
Now, Vadim proposed the notion of having serializers that write on
output streams which are not connected to the requesting agent.
Something like this
request -> g -> t* -> MX -> t* -> s -> response
|
t*
|
s
|
v
stream
this reminded me a lot of transistor 'drains', the place where the
electrons are consumed.
So, ideally, we could have
- a multiplexer/expander/exploder/dispatcher (which is the symmetrical
of the aggregator, but performs as a transformer)
- one or more 'drains', which are generator-less semi-pipelines where
the draining output stream is explicitly written.
So we could have something like this:
<match pattern="...">
<generate .../>
<transform ../>
<route>
<drain element="...." namespace="...." dest="drain://database"/>
<drain element="...." namespace="...." dest="drain://email"/>
<drain element="...." namespace="...." dest="drain://sms-gateway"/>
</route>
<serialize .../>
</match>
where before we had something like this
<map:drains>
<map:drain name="database">
<transform .../>
<serialize .. dest="..."/>
</map:drain>
...
</map:drains>
note the 'dest' attribute of serializers!
we could also change the definition of 'internal pipelines' using
<map:sources>
<map:source name="newsfeed">
<generate .../>
<transform .../>
</map:source>
</map:sources>
and then have
<match>
<aggregate>
<part src="source://newsfeed"/>
</aggregate>
<transform/>
<serialize/>
</match>
So, at the end we get:
1) pipeline: g -> t* -> s
2) source: g -> t*
3) drain: t* -> s
4) aggregator with parts
5) router with drains (bah, don't really like the name router, but I
can't think of anything better)
Comments?
--
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]
