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

Hi Mark,
I am not sure, but digital signature and logger handler scenario would be
helpful.  Assume that a message including digital signature header
as in SOAP Security draft (W3C) is sent, and consumed by a
signature verifier handler.  So far so good.  However, a logger
handler wants to log the message with the signature header
entry.  If the verifier handler removes it, the logger cannot work.
If you envision this scenario with your model, it would be a good help.
I hope that this makes sense.
Best regards,

Yuhichi Nakamura
IBM Tokyo Research Laboratory
Tel: +81-462-73-4668


From: Mark Jones <jones@research.att.com>@w3.org on 2001/03/22 08:31

Please respond to Mark Jones <jones@research.att.com>

Sent by:  xml-dist-app-request@w3.org


To:   jones@research.att.com, moreau@crf.canon.fr
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



     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 Thursday, 22 March 2001 11:17:39 UTC