Re: Summary: 22-24 Sept 2003 WS Desc FTF

Hi Amy,

> > Clearly I haven't understood this pattern stuff at all. I wonder
> > how users will deal with it.
> 
> The multicast solicit-response pattern was "rolled into" the
> solicit-response pattern on the basis of the language that was
> introduced to say that, basically, we only reflect information into a
> pattern description if it is important to more than one participant. 
> The service cares that it is sending a message multicast.  Each of the
> receivers doesn't care; the rules that they follow are to send [no
> response] or [one response] or [one fault].  Multicast solicit-response
> does *not*, in fact, really work terribly well with the existing
> output-input pattern; it would be better to change it by saying 1) it
> uses message-triggers-fault, and 2) the input message is optional.
> 
> If things are truly so confusing, then I will propose adoption of a
> pattern that uses the above modifications, since *that's* what I'm after
> (well, that and a notification pattern with message-triggers-fault).  In
> pub/sub, the *publisher* is the service, and output-first patterns are
> the norm.

+1 to adding this pattern.

> Neither I nor anyone at TIBCO has ever advocated the serial unicast
> "multi" patterns (which I, personally, thought of as simply clouding the
> issues, but I probably shouldn't cast nasturtiums).  Apparently they
> confused lots of people, who associated them with the arguments I've
> made for multicast-capable patterns.  They are completely unrelated. 
> They are *not* my fault.  That we have removed confusion, by removing
> the serial unicast patterns (unless someone else steps forward to offer
> defense), is probably an advantage to the readers of the spec, who won't

So it looks like it was Roberto playing mind games with us ;-). I 
think he's running as far away from them as possible .. so I doubt
anyone will defend 'em any more. Let's nuke 'em!

> have all the backstory about multicast and the rest of it.  I do not
> regard this decrease of confusion as a good reason for removing the
> material that *does* support multicast.

I'm not proposing that any more. At one point I was advocating 
removing all patterns that we're not defining normative bindings
for, but now that we are not following that rule I'm for defining
all the patterns that have well-defined semantics and that someone
deeply cares about. Since adopting these patterns is relatively
low-cost (giving a URI and proper specese just to define the pattern)
across the plethora of specs we have, I fully support adding the
multicast patterns as well.

Sanjiva.

Received on Tuesday, 30 September 2003 15:41:40 UTC