[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Issue 130 - DPWS - Fault Handling Clarification Needed
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]