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

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

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