Re: Enumeration state tables

More inline

On 9/28/2009 4:38 PM, Doug Davis wrote:
>
> Comments/questions *inline*
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
>
>
> *Gilbert Pilz <gilbert.pilz@oracle.com>*
>
> 09/28/2009 11:23 AM
>
> 	
> To
> 	Doug Davis/Raleigh/IBM@IBMUS
> cc
> 	"public-ws-resource-access@w3.org" 
> <public-ws-resource-access@w3.org>, 
> public-ws-resource-access-request@w3.org
> Subject
> 	Re: Enumeration state tables
>
>
>
> 	
>
>
>
>
>
> Comments inline
>
> On 9/27/2009 12:54 PM, Doug Davis wrote:
>
> Couple of comments:
> 1 - if we're going to do this then I'd like to suggest that we get 
> some version of these into the spec sooner rather than later.  Having 
> this in the spec sooner will people more time to review it - including 
> non-WG members.
> <gp>I would like that as well.</gp>
> 2 - We probably need an [End] state - in both tables
> <gp>Why? As there is no state you can progress to after entering the 
> [End] state, it seemed to me that there was no need to include it in 
> the tables.</gp>
> *<dug>  I was wondering if having an [End] state would help clarify 
> the fault cases.  In other words, what is supposed to happen if the 
> enumeration is in the [End] state but gets a Pull?  *
> *</dug>*
<gp2>To be clear, again, both the consumer and the source *have* an 
[End] state, it's just that it isn't shown in the tables. I can see how 
depicting the source's [End] state would make sense. For the consumer, 
though, it would seem that, once the enumeration reaches the [End] state 
you should ignore any and all responses related to that enumeration</gp2>
> 3 - on the consumer side - when we're in states like "Getting Status", 
> can't we also do a Renew?  No need to serialize things, right?
> <gp>Correct. I didn't mean to imply that we should serialize 
> operations on the enumeration.</gp>
> *<dug> I was probably over thinking it - never mind </dug>*
>
> 4 - do we need to say what happens if a GetStatusResponse comes in but 
> we're not in the "Getting Status" state?  if not, then I'm not sure we 
> need the "Getting Status" state.  If fact, this state could cause 
> confusion because it implies you can't do a Renew while in that state.
> <gp>If the consumer receives a GetStatusResponse when it has not sent 
> a GetStatus message (an event that would have caused it to enter the 
> "Getting Status" state) that would seem to indicate that there is 
> something wrong with the implementation of the source. It's true that 
> a consumer could simultaneously be in both the "Getting Status" and 
> the "Renewing" states. I'm not sure how to handle this other than to 
> note it at the end of  the table.</gp>
> *<dug>*
> *when I asked this question i think I was wondering about the case of 
> a really delayed response - ie. no RM.  So the client doesn't get a 
> GetStatusResponse and is impatient so it sends another GetStatus. 
>  This time is does get the response.  But then later the original 
> GetStatusResponse comes in - what should it do?  As with the previous 
> one, perhaps its too much of an edge case and I'm in the weeds.*
> *</dug>*
<gp2>I built the tables under the simplifying assumption that no 
messages would be lost or "significantly" delayed. Obviously this 
assumption will not always hold true in the real world, but it's not 
clear to me how much the tables would benefit from the removal of this 
assumption. Remember the purpose is to provide developers with a clear 
picture of how the protocol is supposed to operate. Perhaps it would be 
good to allow for some generality (like removing the "Getting Status" 
state and simply allowing for the arrival of GetStatusResponse messages) 
but it seems to me that, if we try to picture all the combinations 
possible via retried requests, etc., we will end up with something that 
is more confusing than helpful. I think we should discuss this at the 
F2F.</gp2>
> 5 - consumer: Expiration while in the Renewing state.... this one is 
> interesting.  From the consumer's point of view, if they get back a 
> fault from the renew then they're not back in "Created" state, they 
> should be in "End" state.
> <gp>To be clear, "Expiration" is a "timer" not a "msg" event. That is 
> to say, it is triggered by an internal timer, not the arrival of a 
> message. My thinking was that, if the consumer sends a Renew message 
> then, while awaiting the RenewResponse its timer goes off, it should 
> continue to wait for the response since that will tell it 
> unequivocally what the state of the enumeration is.
> *<dug> this one might depends on the serialization topic from above. 
>  Is a client allowed to send a Pull while waiting for a RenewResponse? 
> If so, then it seems like the Expiration event should cause the client 
> to go from Renewing to End because regardless of what the 
> RenewResponse says the Enumeation really shouldn't be used any more- 
> which is why for all other initial states the Expiration times moves 
> us into the [End] state </dug.*
<gp2>I'm not sure what sending a Pull has to do with this. There are two 
things at play here. Firstly, the consumer's idea of when the 
enumeration expires is not definitive; the source is the ultimate 
authority on whether on not the enumeration has expired. Secondly, a 
Renew request is a request to reset the expiration timer; a 
RenewResponse normally causes the consumer to update it's expiration 
timer based on the expiration value. If the consumer goes to the [End] 
state in this situation, and the source had honored the Renew request, 
you have just caused the source to grant a new lease on an enumeration 
that will never be used because the consumer thinks it has expired.</gp2>
> 6 - on data source, the Pull request should probably have the if-stmt 
> only on the sending of the EndOfSequence element since it could appear 
> _with_ data too.
> <gp>That's what I meant to communicate. Feel free to modify the text 
> as you see fit.</gp>
> *<dug>*
> *would this work?*
> *- - - - - - - -*
> *send wsen:PullResponse*
> *if (end of sequence) {*
> *  include wsen:PullResponse/wsen:EndOfSequence*
> *  [End]*
> *}*
> *else {*
> *  [Created]*
> *}*
> *- - - - - - - -*
>
> *</dug>*
<gp2>Looks OK to me.</gp2>
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  _dug@us.ibm.com_ 
> <mailto:dug@us.ibm.com>
> The more I'm around some people, the more I like my dog.
>
> *Gilbert Pilz **_<gilbert.pilz@oracle.com>_* 
> <mailto:gilbert.pilz@oracle.com>
> Sent by: _public-ws-resource-access-request@w3.org_ 
> <mailto:public-ws-resource-access-request@w3.org>
>
> 09/11/2009 07:31 PM
>
> 	
> To
> 	_"public-ws-resource-access@w3.org"_ 
> <mailto:public-ws-resource-access@w3.org> 
> _<public-ws-resource-access@w3.org>_ 
> <mailto:public-ws-resource-access@w3.org>
> cc
> 	
> Subject
> 	Enumeration state tables
>
>
>
>
> 	
>
>
>
>
>
>
> Attached is the first draft of the state tables for WS-Enumeration. 
> Overall this was pretty straightforward. The one thing I'm not sure 
> about is, when the Consumer is in the "Releasing" state (having sent a 
> wsen:Release request) and it receives a fault that is not 
> wsen:InvalidEnumerationContext it seems that the Consumer has no 
> choice but to assume the request wasn't processed and the Enumeration 
> is still in the "Created" state.
>
> While working on these state tables it occurred to me that the issues 
> around expiration representation and expiration negotiation that we 
> are discussing for WS-Eventing are also issues for WS-Enumeration.
>
> - gp[attachment "Enumeration-State-Tables-v1.doc" deleted by Doug 
> Davis/Raleigh/IBM]