Daniel Fagerstrom wrote:
> I have done some more thinking and have started to build a prototype. I
> decided that it would be easier to build it in the treeprocessor, so I will
> describe the design this far in terms of the treeprocessor interfaces and
> classes.
<snip/>
> Given that the design above actually work, it seem possible to implement
> pipe-aware selection without messing with any interfaces at all in Cocoon.
Ok, good.
> The somewhat implicit transport of the dom-tree is maybe a kludgy solution,
> it might be better to have a new interface that makes that communication
> more explicit. But in any case we should _not_ change the Selector
> interface.
Ok, I think we all agree on this point.
<snip/>
> With the design above I think the existing cash mechanisms should be usable
> as is, the EventPipeline before the selection could be cached and then the
> selection mechanism could be applied on the cached data and the content in
> the chosen "when clause" can be cached in turn. But this scheme would be
> unnecessarily inefficient: it would be better to also store a mapping
> between the cash key for the "input pipeline" and the "when clause" that is
> chosen for that input pipeline, so that the tests does not have to be
> recalculated.
ok
> <snip/>
>
> > > Performance: it would of course better to not be forced to store the
> > > SAX-events in DOM-tree, but I do not see much choice.
> >
> > Well, this is not a problem since XSLT processing works this way anyway,
> > but an XPath engine can be made much more incremental than a XSLT-one.
> Might be doable in principle, but I would guess that it could be hard to
> reuse this functionality from an existent XSLT implementation. I have some
> previous (very bad)
> experience from trying to reuse low level mechanisms in Xalan for an
> extension element, and have to forget about that experience before I will
> repeat that mistake ;)
ok
> > Also, it might be possible that not much load is given to these pipes
> > since they are mostly used in data INPUT which is normally much less
> > than data OUTPUT in any site.
> Yes, that is what I believe, IMHO it seem unnecessary to implement
> complicated optimizations before there are clear use cases for them. It
> should also be noted that selection based on validation _can not_ be done in
> streaming mode, the whole document must be validated before we know that it
> is valid, i.e. buffering is necessary.
hmmm, don't know, there are cases where XML validation can be a
sequential process, but the same thoughs on XSLT apply here.
Anyway, I'd love to place your eventual contribution in the scratchpad
and see what people think about it and what performance it gets.
Also, I would love to see how this merges with Vadim's thoughs on
'multiplexers'... but I have the impression that we can work
incrementally, so you shouldn't stop your effort.
Who knows: maybe the new interface you are wondering for above might be
Multiplexer and Vadim could reuse part of your code to implement it.
Bah, dunno, just thinking out loud...
--
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]
