W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2006

Re: Constraints for multicast

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 14 Aug 2006 16:42:44 -0400
To: David Hull <dmh@tibco.com>
Cc: "xml-dist-app@w3.org" <xml-dist-app@w3.org>
Message-ID: <OF3C3ABF34.57A52E5D-ON852571CA.006920A4-852571CA.0071C77D@lotus.com>

David Hull writes:

> Because the MEP looks like a single operation to the sender, I'm 
> skeptical of a multi-MEP solution.  AFAICT, the sender would be 
> participating in a composite operation consisting of 0 .. N MEPs, 
> which all look identical to it.  The zero case looks especially 
> troublesome.  Even if there's no one to hear it, the tree still 
> falls.  Maybe I'm missing something, but this seems like it would be
> a pain to word precisely, and it doesn't seem particularly close to 
> the ether model.

I agree completely with your premise, but not our conclusion.  You seem to 
be providing a very careful analysis of why, someday somewhere there 
should be at least one multicast MEP.  You correctly describe what it will 
look like from sender and receiver, even correctly noting that it is in 
many respects similar to one way, but differs in a least one visible way, 
which is in the possibility of multiple or partial failures as seen from 
the sender.  What I don't think you've shown at all is why this should be 
the same MEP as the one way.  I don't doubt that its use at sender and at 
receiver will be quite similar, as seen in an application API, but an MEP 
is largely a specification for how to write a binding.  The binding sends 
the messages, and what it does for multicast, particularly on certain 
transports, is quite different than for one way.  Furthermore, I think 
trying to do multicast inside the one way will complicate the 
specification of edge conditions in the one way, it will complicate 
terminology like destination address(es) and so on.

I think the right design point is:  do a one way MEP.  Someone somewhere 
does a multicast MEP (maybe more than one), and tries to make sure that 
it's semantics are such that it will be really easy for senders and 
receivers to support the one way and the multicast using application apis 
that are as similar as possible.


Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Monday, 14 August 2006 20:43:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:30 UTC