Re: Thoughts about path and intermediaries

Greetings;

I disagree with the layered approach to single hop/multi-hop issue. If
Routing is influenced by many things, then it must be determined in an
orthogonal way.  That is, it should be possible for a sender to send the
envelope without knowing a priori the path it will traverse.  That leads
me to believe that we should use the word targetable instead of
addressable in the defi nition of intermediaries.

thanks
marwan

Noah_Mendelsohn@lotus.com wrote:
> 
> I sort of agree with a lot of what has been written in this thread, but
> it's easier for me to think about this if I can put it in my own terms for
> a minute:
> 
> * 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.
> 
> * I don't think this is directly about binding to or exposing capabilities
> or compositions of the underlying transport.  If I need to "begin
> transaction"  before I "update catalog", that potentially is true
> regardless of transport.  Yes, there are also transport-specific
> intermediaries:  different issue IMHO.
> 
> * 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.
> 
> 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.)
> 
> ------------------------------------------------------------------------
> Noah Mendelsohn                                    Voice: 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------------

Received on Wednesday, 14 February 2001 07:48:47 UTC