Re: Thoughts about path and intermediaries

On Tue, Feb 13, 2001 at 08:38:47PM -0500, Noah_Mendelsohn@lotus.com wrote:
> 
> * Fundamentally, I think the issue is:  can you in some way express
> either a total or partial order in which various headers must be
> processed?  This is about at the level of mustUnderstand...if you
> get the order wrong, you've got an error.

Perhaps in two dimensions - within the message, and within the path.


> * There have been suggestions to move back to a single hop protocol,
> putting all path-like notions at a higher level, and Henrik
> suggests (I think) to do about what SOAP does today.  My view: if
> path is application level, then I'm not sure why SOAP-ENV:actor
> isn't as well.  Given that SOAP deals at the level of naming
> intermediaries and targeting headers to them, that's very close to
> the level at which you worry about getting to the intermediaries in
> the wrong order.  It feels to me as if actor and header-path come
> more or less together.

Routing (path) is influenced by so many things, both at the
application level and elsewhere. I think that this, more than
anything, is why I've been so cantankerous - it smells like a very
large rathole.


> So, with the caveat that I may be completely missing something, the
> two approaches that seem self-consistent to me are: (a) make the
> protocol single hop, which I think means putting the attributes for
> actor, path, and perhaps mustUnderstand in some higher level
> namespace...which we'll probably have to design in a hurry or (b)
> consider expressing the full or partial order of header processing
> and in that sense a path or route in some standard way in the core
> protocol.
> 
> I'm not 100% sure whether I prefer to see all this in the core or
> layered. Having a core point-to-point single hop protocol has
> always had a certain minimalist appeal, but you can get a lot
> richer routing and decision making if partial orders are visible to
> the routing software.
> 
> In either case, maybe it's as simple as having a mustFollow header
> attribute that indicates (don't process me until you've processed
> (idref of other header)?  If the attribute is missing, no order is
> required.  (we have to think about cycles, etc.)

Interesting; I like that the more I think about it.

Cheers,

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

Received on Wednesday, 14 February 2001 01:39:00 UTC