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

	Date: Wed, 21 Mar 2001 17:00:39 +0100
	From: "Jean-Jacques Moreau" <moreau@crf.canon.fr>
	To: Mark Jones <jones@research.att.com>
	Cc: frystyk@microsoft.com, skw@hplb.hpl.hp.com, xml-dist-app@w3.org
	Subject: Re: mid-course correction on abstract model for module processing

	...

	> but it seems like a single module must be given responsibility for processing them

	I disagree. I don't see why we should constraint what Senders can send to Receivers. IMHO,
	Senders should be able to send any kind of Blocks to Receivers, *in a single message*.

	> and determining a result.

	or results (ie, blocks)?

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...  :-)


	> 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?

--mark

	Jean-Jacques.

Received on Wednesday, 21 March 2001 18:31:15 UTC