Arnaud Le Hors wrote:
> Given the numbers you get, I hope Andy will agree this time, or will 
> come up with some practical reason not to do that (I only ever got FUD 
> from him on that one in the past. ;-)

My objection was not against dynamically modifying
the pipeline. My objection was against allowing the
components control over the pipeline. In my view of
XNI, the parser configuration is in control of the
components, not the other way around.

Having said that, I can also say that now that XNI
has been around awhile, I think we know more about
how it behaves and how to write new components and
new parser configurations. As such, providing more
power and flexibility is certainly a reasonable goal,
especially if it improves performance but only if
it doesn't hurt the XNI core.

So, in general, I don't like changing XNI to allow
components to control the system. But at the same
time, I won't oppose this addition if that's what
people need/want.

> This said, I claim that the setSourceDocument method ought to be on 
> XMLDocumentHandler instead of XMLDocumentFilter (which will then inherit 
> it from XMLDocumentHandler). And to make "editing" the pipeline more 
> convenient we should had the related getters to XMLDocumentHandler and 
> XMLDocumentSource.

The particular change suggested doesn't require
the addition of getter methods. So I have to ask
if we really need them at this time? That would
give each component the ability to completely
traverse and modify the pipeline.

I guess it's not that big of a stretch given the
other change, though.

> Yes. One additional possibility is to specify that setDocumentHandler calls 
>setDocumentSource. This way the application only has to do:
> 
> f1.setDocumentHandler(f2);
> 
> which does: f2.setSourceDocument(this);

This would be more convenient for the caller but
I would prefer to keep the calls explicit instead
of having things get re-arranged implicitly like
you suggest.

-- 
Andy Clark * [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to