W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2001

Re: mid-course correction on abstract model for module processing

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Thu, 22 Mar 2001 17:30:46 +0100
Message-ID: <3ABA28B6.91086B36@crf.canon.fr>
To: Mark Jones <jones@research.att.com>
CC: frystyk@microsoft.com, skw@hplb.hpl.hp.com, xml-dist-app@w3.org
Mark Jones wrote:

> I am now leaning toward a model where any of the handlers that execute
> at the destination can contribute blocks for the return message.  If
> we furthermore avoid the header/body distinction then you don't even
> have a buffering/serialization problem if the handlers execute
> serially.  Simpler and better...  :-)

That sounds great!

>         > In the case of header blocks, they can all be individually targeted.
>         > [...]
>         >         I am concerned by us automatically removing blocks as soon as they are
>         >         consummed. I think there are cases where you do want to keep consummed
>         >         blocks from one intermediary to the next, and I would be reluctant to
>         >         us having to use the push(pop()) kludge, instead of solving the issue
>         >         properly. If we really want this functionality, shouldn't we at least
>         >         make it optional?
>         >
>         > This is the purpose of "none".  Multiple targeted blocks could link
>         > to a non-targeted block.  Each targeted block gets removed as it
>         > finds a module capable of processing it, but the non-targeted blocks
>         > would not be removed.  If the sender wanted to target several
>         > different intermediaries/modules with the same info, he would include
>         > separate targeted blocks linking to the common block.  Each targeted
>         > block will disappear one-by-one, but the untargeted block would survive.
>
>         "None" does not answer my concern.
>
> I'm not sure why not.  [It is not push(pop()).]  What is the use case
> that you have in mind?

I have just been rereading your message with a fresh mind, and I think the solution you propose would
satisfy my needs, albeit at the expense of extra blocks.

I am still wondering, though, why we require that consummed blocks are not forwarded further. (It
sounds like it would require Processors to do a lot of XML cut-and-paste, which may be expensive.)
Anyone with a good answer? Henrik?

Jean-Jacques.
Received on Thursday, 22 March 2001 11:31:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:59 GMT