Re: xp requirement document specifies headers

On Wed, Jan 24, 2001 at 09:08:15AM -0800, Mark A. Jones wrote:
> > Re: xp requirement document specifies headers
> >
> > From: Hugo Haas (hugo@w3.org)
> > Date: Wed, Jan 24 2001
> > ...
> > I remember a discussion about an XP processor starting to process a
> > message (for example starting to send an XP message back with a
> > response to an RPC) and then being forced to generate a fault, which
> > makes me think that indeed XP messages have to be processed as a
> > whole.
> >
> > On the other hand, R309[2] is about resource constrained device. As
> > Noah pointed out[3], the issues related to resource constrained
> > devices have not been discussed in detail; I could imagine a system
> > with very limited memory wanting to process an XP message "on the
> > fly".
> >
> > So I think that it is an open issue. But I agree that not considering
> > XP messages as a whole will lead to complication, and that to keep the
> > processing model simple, considering XP messages as a whole is a good
> > idea.
> > ...
> 
> Some of the usage scenarios/cases [DS21] anticipate SAX-style incremental parsing and processing of XP messages
> by the recipient.  Long messages could conceivably never be fully stored anywhere!!  They could be written on
> the fly by the sender, incrementally passed through intermediaries and incrementally processed by the
> recipient.  While it is true that one can imagine XP processing requirements in some cases that require a
> complete pre-pass, it would be best if this does not become a hard and fast requirement or design feature.

Well-formedness and fault implications of message-based protocol:
--------
I propose that the base protocol be message-based and that the
messages be _assumed_ to be well formed, ie. that the processing
agent not be responsible for checking the well-formedness (much less
the validity) of the message. There are many protocol servers out
there that do not do an exhaustive test of the validity of incoming
requests.

Security concearns may well force you to be more fussy about the
request coming to an xp server that is open to the public than an xp
server communicating with a small set of well-established agents. The
fussy server may be more vigilent about noting and throwing faults.

Streaming optimization implications of message-based protocol:
--------
Optimizations for separating out the non-default agents and the post
message checks may be stacked on top of the underlying protocol via
popular modules invoked in blocks in the message. One could then
design xp agents that _only_ worked if those blocks were present. That
would allow hand-held devices and heavily loaded proxies and servers
to handle large documents efficiently.

These extensions may become very popular, to the exclusion of the base
protocol, but the blocks used to invoke these modules need not be much
more expensive to serialize than the SOAP-ENV:Header and the
SOAP-ENV:Body tags and they can be kept as optional modules so
processors of the base protocol may still process the optimized
messages.

-- 
yours for an orthogonally extensible world,
-eric

(eric@w3.org)

Received on Wednesday, 24 January 2001 15:17:00 UTC