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

Mark,

Thanks for your comments, and sorry for the late response.

Mark Jones wrote:

>         There has been some discussion in the past as to whether we should
>         keep the (somewhat artificial) distinction between headers and body.
>         Are you suggesting that we should keep both, instead of just having
>         blocks?
>
> This will become zero or more blocks in a header and zero or more
> blocks in a body -- blocks are various referred to as "entries" or
> "parts" in SOAP.

Ok.

> The main distinction as I see it is where the
> responsibility lies for generating responses.  Some handler in some
> module at the destination must take on that responsibility, and having
> a body makes a convenient place to designate that responsibility.

That's fine. We could do it differently, for example using an attribute or special URI;
this would, in my opinion, simplify the dispatching machinery (no need to look for a body
tag; just use actors and namespaces everywhere, it will work automatically). But you are
right in pointing out we need to carry out the "body" semantics, somehow.

>         Also, how would I be able to send two RPCs to an XMLP Receiver via a
>         single XMLP Message if a Message can only carry one body
>         block?
>
> I don't think having multiple body blocks is a problem,

Ok.

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

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

Jean-Jacques.

Received on Wednesday, 21 March 2001 11:01:45 UTC