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

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

From: Laird A Popkin <laird@io.com>
Date: Thu, 15 Mar 2001 11:26:15 -0600 (CST)
To: Jean-Jacques Moreau <moreau@crf.canon.fr>
cc: "Mark A. Jones" <jones@research.att.com>, Henrik Frystyk Nielsen <frystyk@microsoft.com>, Stuart Williams <skw@hplb.hpl.hp.com>, John Ibbotson <john_ibbotson@uk.ibm.com>, Krishna Sankar <ksankar@cisco.com>, Lynne Thompson <Lynne.Thompson@unisys.com>, Marc Hadley <marc.hadley@uk.sun.com>, Martin Gudgin <marting@develop.com>, Nick Smilonich <nick.smilonich@unisys.com>, Oisin Hurley <ohurley@iona.com>, Scott Isaacson <SISAACSON@novell.com>, Yves Lafon <ylafon@w3.org>, xml-dist-app@w3.org
Message-ID: <Pine.LNX.4.21.0103151123110.32135-100000@fnord.io.com>
ICE (content syndication) certainly has multiple things in the "body" but
it's easy enough to solve that by having a single body entity containing
one or more requests or responses (which is what ICE sends).

Why pack multiple "messages" in one message? Huge performance gains,
particularly since ICE supports a model where a participant may be offline
(or not running) then appear, push out a bunch of requests, receive the
responses, process them and go away again. Imagine a cron job that runs a
simple command line tool that polls for updated content every ten

On Thu, 15 Mar 2001, Jean-Jacques Moreau wrote:

> Mark,
> Thanks for the rewriting and the hard work, although I must admit I
> preferred the original version. :(
> "Mark A. Jones" wrote:
> >   1. An XML Protocol Message consists of zero or more header blocks
> >      and one body block. [...]
> >
> 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?
> 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?
> >   1. Each header has an optional associated id (identifier), an
> >      optional actor and an optional mustUnderstand flag.  The body
> >      has an optional associated id (identifier) and an optional
> >      actor.  The body must be understood.  The id is an ID that
> >      identifies the block for the purposes of reference by other
> >      blocks.  The actor is a URI used by the XML Protocol Processor
> >      for determining which module to apply to the block. [...]
> >
> Noah has suggested (cf issue 41) that we use two different URIs, one
> for physically identifying the host, one for the identifying the
> service. Wouldn't this have an impact on the actor attribute?
> >   1. There are reserved actor URI's with special significance:
> >        http://.../none       // matches no module (i.e., an
> >      untargeted header)
> >        http://.../next       // matches a default module at the next
> >      processor
> >        http://.../final      // matches a default module at the
> >      final processor
> >        http://.../body       // matches the module selected at the
> >      final processor (can be used as a target for headers)
> >      [...]
> >
> Don't we need some lower level of granularity in these URIs, so we can
> address, for example, a particular handler?
> Also, shouldn't the URIs be HTTP agnostic, if we claim we are
> transport independent?
> >   1. When a header is selected for processing by a module at an
> >      intermediary, the header is removed from the envelope.  [...]
> >
> 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?
> >      The processing of a header may result in a fault or a
> >      successful evaluation.  A fault terminates processing and
> >      causes a return message containing the fault to be generated if
> >      a return path is available. [...]
> >
> Does a fault terminate all processing, including forwarding to the
> next hop; or does it only terminate processing at the current node,
> with forwarding still happening? The text probably requires some
> amount of clarification.
> I hope this helps,
> Jean-Jacques.
Received on Thursday, 15 March 2001 12:30:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:12 UTC