Berin Loritsch wrote:
> > 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, I want to interject that it is easier to understand the usefulness
> of Aggregations than Views. For that reason, we need another way of
> viewing the system.
yes, I know, contributions on this are very welcome :)
> > 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.
>
> I understand the requirement. What we need is the ability to
> initiate asynchronous pipelines that consume information from a
> request. I say asynchronous because in this case, we are not
> merging the information back into the critical stream.
Yes. The problem being when the result of one branch is 'synchronous'
with the result of the other branch. (say, saving something into a
database)
> There has been some talk about making SAX streams concurrent (i.e.
> an aggregation of several pipelines all running at the same time
> to reduce time to the client). So the Multiplexer/Demultiplexer
> idea does have some merit.
>
> However, let use take the abstraction up from the FET analogy.
>
[snipped very interesting parallel on cocoon and audio processing]
> The closest thing we have to a signal router in Cocoon is the Sitemap.
Agreed.
> The sitemap does not provide a soft-wiring feature that assists in
> creating a solution.
I midly disagree here: continuing on your parallel, a compiled sitemap
is nothing different from an electrical circuit that is hardwired with
special capabilities and then used in production.
On the other hand I see an interpreted sitemap equivalent to a
soft-wiring, sort of a test-board where you conntect your components,
try them out and see when they do what you want.
Then you go and assemble your board (if you ever compiled VHDL or
Verilog into circuits you know what I mean, but that's *way* down to the
metal for the people on this list, I guess).
> We only have hard-wiring which means that we have
> to explicitly state how we handle each invokation of the sitemap. Many
> HTTP servers provide a soft-wiring that matches urls to the file system.
This is nothing different from the sitemap: we could easily have an
implicity rule such as
<match pattern="**">
<read src="{1}"/>
</match>
and that would clone the default HTTP functionality, but there is
nothing "soft" in the function of this.
> This is an easily understood default that is as fragile as your file
> hierarchy. I don't have any thoughts on how to provide a middle of the
> road soft-wiring for the sitemap.
I don't see the concept: a soft-wired sitemap would be a sitemap that is
able to modify itself at runtime. It has been proposed (a.k.a. dynamic
sitemap) but nobody has yet came out with a meaningful example that
*required* that and could not be processed with a better separation of
concerns between the pipeline components.
> One of the areas that we are facing (as the additions of views and
> aggregations attest) is that the sitemap semantics do not provide a
> balanced and flexible approach to signal (request/response) routing.
Yes, I think we all agree here.
> I think that the addition of Actions can attest to that. Lets take
> Cocoon and instead of a web application platform lets place it in the
> light of a web services platform (all XML all the time).
[snipped discussion on web services platform built on top of cocoon]
The more I think about it, the more I think Actions don't belong to the
sitemap... but to be entirely honest with you, I don't have a clear view
of where we should lead the semantics to.
I see great promises in Ovidiu's work on Schecoon... but we also need a
way to make the two things (flowmaps and sitemaps) interoperate yet
keeping concerns separated and keep the number of contracts the smallest
possible.
And this is *not* an easy architectural task :/
> (Stefano, I know I went a completely different way than you started
> out but I think we have something to throw in the mix here that will
> get us closer to where we want to be).
Hey, RT were written exactly to do this :) no need to explain yourself.
--
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]
