From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
> Nicola Ken Barozzi wrote:
>
> > My opinion is that developers are not yet taken correctly into account.
> > While the other three have a componentization which is sufficient for
their
> > part of work, developers suffer for the lack of it. Usually a developer
has
> > to write a component, and doesn't have a (sub) component model to deal
with.
>
> ??? I disagree, you can write avalon-aware sitemap components by hand
> (and many people do just as easy as they write servlets... or even
> better).
Yes, this is right, but I would also like a *sub*Component model.
Components to make Cocoon Components, so to minimize impedence mismatch
between Java and XML.
With Ricardo, we agreed that somehow Java and XML intermingling is bad, and
that they should be separated.
Generators don't do it, and have a fixed schema.
> > Also, Cocoon components do not have scope and filter all events coming
> > in (security: I don't want sensitive tags passing in a transformer that
is
> > useful but not completely known).
>
> please, let's get real here: I *strongly* doubt you'll ever use a filter
> in your pipeline that you don't trust. Security is ok, but at this
> granularity becomes a nightmare (and a serious performance limitation)
I tend to agree, but I'm no sys-admin.
This concern came from a boss you know well... ;-)
> > A----------------------------
> > First we have to change slightly the notion of cocoon pipeline
components
> > introducing scope.
> > Pipeline components need not access <all> SAX events but only what
pertains
> > them. This also means that the pipeline coulde be evaluated eventually
in
> > parallel
> > fashion, improving scalability in heavy processor intensive or high
latency
> > pages.
> >
> > For example let's say that we have this XML:
> > <page>
> > <longquery name="account"/>
> > <query name="username"/>
> > <page>
> > Let's say that in another file (the developer's sitemap) is written that
> > query tags must be processed by the foo.sql.QueryTransformer and the
> > longquery tags by acme.sql.BankTransformer.
> > As SAX events come into action the start page tag is directly sent to
the
> > serializer.
> > Then the acme.sql.BankTransformer is given only the longquery tag and
starts
> > processing in a non-blocking fashion.
> > This means that SAX events can continue and parallely
> > foo.sql.QueryTransformer can start processing his tag.
> > Now the pipeline has to wait for the first transformer to finish because
> > embedded tags link page cannot be processen in non-blocking fashion.
When
> > they finish their output events are outputted in order and finally the
last
> > page tag.
> >
> > As you can see if there are transformers that take longer to perform
(also
> > because of latency of DBs and likes) they can be performed this way in
> > non-blocking fashion, speeding up total response time.
>
> And this should be KISS?
Ok, so let me explain it from a sitemap view.
You can add a parameter parallel="true" to make queries run simultaneously.
Simple enough?
> > B----------------------------
> > A global context-aware object broker could also be inserted in the
scheme.
> > This doesn't really change the framework, it's just a useful addition.
>
> Don't forget we can still use Alberto's X:Forge for this.
Where is it? <hint, hint, nudge, nudge ;-)>
> > C----------------------------
> > Now let's explain how a finer-grained object model can be devised.
> > First of all it must be capable of specifying a pipeline component as a
sum
> > of smaller components possibly only by writing XML described "glue".
> > I's like:
...
> What you propose is similar to X:Forge and to DXML that Ricardo was
> working on (I say 'was' because I can't reach him anymore :( but was
> much simpler:
Similar yes. I still remember the very interesting brainstorming I had with
them on these.
> I'd rather attach X:Forge to Cocoon (at the generation level) than
> having to write something so complex at the pipeline level.
X:Forge is ok for me, but where is it? Can you put it in the scratchpad?
> I think the tokenize/detokenize part are really far from my view of
> keeping it simple and go into a deep mess.
Ok. Could be true.
Only live code can be really discussed, we'll continue this at that time.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
