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

Sanjiva Weerawarana wrote:
> 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 ;-).

A truly Machiavellian plan, bwah ha ha! I even took the precaution of
erasing it from my own memory, so as not to betray myself!  ;-)

> 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!

+1

>>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.

I still support your original position, hence I disagree with making
this pattern normative. How about the compromise of having the pattern
Amy proposes in a non-normative appendix to the patterns spec? We define
it properly, assign it a URI, use it to elucidate the patterns
framework, make it available for anybody to use it (if they have
a binding for it, that is), but it's *not* normative.

Roberto

-- 
Roberto Chinnici
Java Web Services
Sun Microsystems, Inc.
roberto.chinnici@sun.com

Received on Tuesday, 30 September 2003 17:37:57 UTC