- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Thu, 22 Mar 2001 17:30:46 +0100
- 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 UTC