Re: Enumeration state tables

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

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> 
Sent by: public-ws-resource-access-request@w3.org 
09/11/2009 07:31 PM 


To
"public-ws-resource-access@w3.org" <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]