Re: NEW ISSUE: Handling arbitrary sets of associated endpoints

A few points, in no particular order:

    * I'll note that these comments were clearly marked
      "BlueSkySpeculation", so I'm not going to defend any of them with
      any great deal of energy.
    * I agree that faults, or something materially like them, /are/ one
      way of dealing with errors in the asynchronous world.  My main
      point was that they're not universally applicable there.  For
      example, if I broadcast a one-way message to a gazillion
      subscribers, I may well /not/ want to hear faults coming back. 
      This would be a case where dropping errors on the floor might well
      be an acceptable strategy.
    *  From the brief look I had, I liked SSDL, particularly its
      extensibility story.  Actually demonstrating two or more clearly
      distinct extensions that might otherwise have been treated as part
      of the core makes a pretty convincing case.  One may draw one's
      own conclusions as to how this relates to WSA.

Savas Parastatidis wrote:

>Hey David,
>
><snip />
>
>  
>
>>In short, I don't think faults make much sense outside
>>request/response.  Even in request/response, they're more a
>>well-established convenience for binding to languages that use
>>exceptions than they are an inherent necessity.
>>
>>    
>>
>
>
>Since faults are messages that carry 'something went bad' semantics,
>they do have a place in other MEPs apart from request/response. I
>personally don't see faults as a mechanism to deal with exceptions at
>the implementation (e.g. procedure/method call exceptions), which if I
>understood correctly is what your message suggested.
>
>Although difficult to support in WSDL, there may still be ways of
>describing more complex MEPs than request/response. In such MEPs, fault
>messages may have a place in conveying protocol or application fault
>semantics. For example, imagine the following MEP that a service may
>support:
>
>msg 1 in -> msg 2 out -> msg 3 in -> (fault msg 1 out) OR (msg 5 out ->
>msg 6 out -> msg 7 in -> (msg 8 out OR fault msg 2 out))
>
>These are the kind of protocol interactions for a service we can
>describe with SSDL (http://ssdl.org). The messages are part of a single,
>multi-message protocol exchange.
>
>Regards,
>.savas.
>
>  
>