[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Issue 130 - DPWS - Fault Handling Clarification Needed
Also, I’d like to add a concrete proposal to the mail below: I
propose that we accept the normative change to R3020, but not add the
explanatory paragraph. From: Dan Driscoll
[mailto:Dan.Driscoll@microsoft.com] The normative addition makes sense—we don’t want services to
send a SubscribeResponse if the subscription failed, or if the service intends
to fault immediately afterward. I prefer that the spec stay silent on the case where the service
does not know about its own events ahead of time. I expect many
implementers wire the list of Actions into their Subscribe handler specifically
to handle this case (and that’s a good thing), so anyone who doesn’t feel like
plumbing this list into Subscribe could arguably be in a “dynamic environment”
where they don’t know what events are available when they receive the
Subscribe. That said, I realize there are very valid technical reasons why
the service may not know at Subscribe time, but I prefer that those
implementers deal with that on a case-by-case basis. The current pattern is very simple, and lets higher-layer specs
be very straightforward about how they define optional events without having to
worry about the case where the service may be in a “dynamic environment.” Thanks Travis --D From: Ram Jeyaraman
[mailto:Ram.Jeyaraman@microsoft.com] This issue is assigned the number 130. For further
discussions on this issue, please refer to this issue number or use this
thread. From: Travis M Grigsby
[mailto:travisg@us.ibm.com]
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]