Re: Proposal for new last call issue: Some unprocessed headers should stay

Jean-Jacques,

I was not saying that a given message path cannot contain multiple nodes
playing a given role (the role 'next' is a good example here) but from
the POV of the sender, the message path contains just one such node
because it eats all headers targeted to it.

I also prefer the added attribute, but I think the changed default is
the second best solution and the proposed special role 'relay' is not a
good solution because it doesn't do enough to justify itself.

Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/


On Thu, 2002-10-17 at 17:05, Jean-Jacques Moreau wrote:
> 
> Interesting you think the spec currently supports 1). My own 
> reading is that it supports 2), i.e. there may be multiple nodes 
> on the message path that play the exact same role, for example 
> logging.
> 
> Actually, if think I really prefer the "relayIfNotProcessed" 
> solution. As I've said earlier, it's not always possible to 
> determine whether a header needs forwarding based solely on the 
> header itself. There has to be some other information, whether in 
> the message or out-of-band.
> 
> Currently, this extra information is in module specifications 
> only, i.e. it has no real incarnation but ink on paper. I am in 
> favour of making that information explicit.
> 
> Jean-Jacques.
> 
> Jacek Kopecky wrote:
> > 1) (status quo) the message path contains some nodes and some roles, and
> > the mapping from a role to a node is unambiguous. In other words, a role
> > name identifies at most one node (from the POV of the sender) and the
> > contract is between the sender and that node
> > 
> > 2) (after proposed default flip) the message path contains some roles,
> > the contract is between the sender and the role (anyone playing the
> > role).
> > 
> > I think Henrik assumes the first view but wants to make an exception for
> > a specific scenario.
> > 
> > I think the specific scenario is very close to the second view so I
> > thought that view was being adopted here.
>