See also: IRC log
<trackbot> Date: 01 June 2010
<scribe> scribe: Dug
<scribe> scribenick: Dug
<Zakim> dug, you wanted to add a new topic to the agenda
agenda is approved with addition
Wu: describes issue
... Min supported should be subscribe/unsubscribe
... will make ws-eventing light weight and useful
... mandatory features should be the common denominator
... can't profile out required features
resolution: new issue accepted for consideration
Katy: what if they tried to use Renew? would WSA fault be returned?
Wu: WSA would cover it and we'd add a policy assertion
Katy: why were they made mandatory?
Wu: explains why he thinks they
should be required
... makes impl harder to do timers - assuming expires is supported
Dug: feel strongly that GetStatus
should remain - w/o it we have no way to know if a subscription is
... Renew, a little less strong but still leaning towards it since its cheap to support
Rick Landau joined the call - from dmtf wsman wg
continue on mailing list
Gil: WSDL is now in its own
... we can update our ref to section 5
Bob: ETA on publication?
... need a board approved draft
... not completed profile, just board approved draft, to go to CR
... for REC we need a completed profile
Ram: how will we ref it?
Rick: talks about the requirement
... permit enumResponse to include the results of the first pull operation
... w/o optimization then just the enumContext is returned
Bob: during f2f we talked about
... during Pull you specify a lot of options
... Enumerate() would want to have the same options
... so why not just merge Pull and Enumerate into one op
... fold Enum into Pull
Rick: would have done it the other way but same end result
Tom: reaction was to the title "small
result sets", just an optimization which might mean everything, but
could just mean the first set
... didn't catch that it was for both, large and small result sets
Rick: trying to reduce the network traffic by one MEP
Tom: pull has lots of parameters - adding this might not be that bad
Dug: would prefer this to dup'ing Pull parameters into the Enumeate
Gil: we talked about complexity
around dup'ing Enum params/faults.... in Enumerate
... the other way, getting rid of enumerate(), we lose the ability to setup many enums w/o actually pulling anything
... we lose this bit of functionality
Bob: couldn't you just pull for zero items
Gil: I recall people saying "blah"
... no strong advocate for the usecase
... during the f2f
... I'm concerned about the tie to CIM's notion of polymorphism
Rick: understood - that's why they
changed the focus to be on just reducing network traffic
... network traffic has been a bit issue for impls
Bob: if we proposed Pull+implicit Enum, would that meet your needs?
Ram: would prefer to have two
... there are things you do during Enum vs Pull
... but see the need for the optimization
... proposal from Dell is preferred
Dug: Gil can you elaborate on the polymorphism thing?
Gil: don't worry about it
... just focus on network traffic
<gpilz> where is Rick's latest proposal?
Tom: how often will the params
... not a big change
Dug: duping everything across Enum and Pull is going to be ugly and a pain for extensions who will need to do the same thing
Bob: u ok with a Pull of zero items?
Bob: Ram, you?
Ram: need to examine the practical
implications of both
... no strong opposition at this time, but no final position
Bob: who will write up a proposal?
Ram: I like Dell's proposal
Tom: adding params from Pull into Enum might not be that bad
Bob: Ram are you willing to promote Dell's proposal?
<Tom_Rutt> I think that if every pull has the same size parameters, it would make sense to put the params on the enum request, allowing the first pull and subsequent pulls to use those size params.
Ram: ok with Dell to come back with a more detailed proposal
Tom: adding the size params to the enum would work
Rick: mentions this in the doc (link above)
Ram: can work with Rick on a cleaner proposal
Bob: need a directional decision
<gpilz> uploaded Rick's expanded use case and motiviation discussion: http://www.w3.org/Bugs/Public/attachment.cgi?id=886&action=edit
Dug: what's the concern with a Pull that just asks for zero items?
Tom: confused about the proposal
Dug: get rid of enum and move the feature under Pull
Ram: wsa:Action is enough to know
what to do
... preference is to keep it separate
... if WG wants to merge into a pull I'll need more time
Bob: what about a Pull child to
... basically batching
... all children of Pull can appear under Enumerate/Pull
Tom: pull child to enum might work
Gil: interesting idea but it might
not be that easy
... what about maxTime?
... would the enumContext still be created during the waiting time?
Bob: same issue if we merged pull and enum
Gil: yes applies to all cases
... this is the complexity we were talking about
Bob: there is no escaping the complexity :-)
Tom: leaning now towards CWNA
... keeping the http connection open isn't that expensive
... Rick, why do you see this as an important optimization when the data on the enum is small and you can just keep the connection open?
Rick: our experience is that the # of
turn-arounds is the problem
... not keeping the connections open makes it worse, but we do keep them open today
... its the turn-around that's the issue
... its double in the current model
... its not the tear-down of the tcp/ip connection
Bob: a) add pull param to enum
... b) add enum flag to pull (remove enum)
... c) add Pull child to Enum
... c - implies Pull child is a full Pull - like batching. a - means we dup the params across the two ops
Tom: what's the fault model?
Bob: both enum and pull faults could occur
Gil: would a pull fault still allow the enum to be created?
Rick: fault would mean no context is created
IBM: no, yes, yes, yes
Hitachi: abs, abs, abs, abs
<gpilz> Oracle (in order): d, c, b, a
Oracle: yes, yes, yes, yes
MSFT: yes, no, yes, no
SAG: abs, abs, abs, abs
<Tom_Rutt> no no yes yes
Avaya: abs, abs, abs, abs
<asoldano> sorry, did confusion with the mobile, but it's abs for all
w3c: yes, no, yes, yes
Fuj: no, no, yes, yes
Redhat: seems to have dropped
a and b go away - no objection
Redhat: abs, abs, abs, abs
c - add a Pull child to enum
Bob: who will write up the proposal?
Ram: Rick would you be willing to work with me on this?
Bob: Rick, will this satisfying your needs?
Rick: not sure how this works from a soap point of view
<scribe> ACTION: Ram to write-up a proposal with Rick's help for Enum optimization issue [recorded in http://www.w3.org/2010/06/01-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-165 - Write-up a proposal with Rick's help for Enum optimization issue [on Ram Jeyaraman - due 2010-06-08].
Rick: no way to know if a subscription is persistent
Bob: been involved in a ton of
discussions about persistence - how long? how is it done?
... across failure of persistence mechanisms
... is it impl specific ?
... subscription lasts until an unsubscribe, times out, any other reason
... can we really define what "persistent" means?
Rick: many different levels of paranoia
none - I want 10 :-)
Rick: (discusses various levels of
"certainty of operation")
... lowest level of persistent subscription
<Bob> how would we test this?
Martin: doesn't the expires mean that the subscription will live that long?
Wu: seems like its coming from not
having a heartbeat
... if we can provide a heartbeat would that address your concern
Rick: heartbeat adds to it
Wu: its a keep alive signal
Rick: keep alive addresses the integrity of the link - persistent doesn't cover that
Wu: persistence is a very huge
... very large promise
Bob: event queue might persist but
subscription could be forgotten
... how might we test this?
<MartinC> im concerned about inventing yet another set of mechanisms that already exist and can be layered e.g. reliable messaging
Tom: the SubscriptionEnd msgs + keep alive/heartbeat seems like it should be enough
Bob: confirm CWNA?
... any objection to cwna?
resolution: close with no action
resolve: close with no action
... impls are free to specify their own level of persistence
Bob: things happening at regular intervals causes network issues
Tom: heartbeats are not always sent,
just when there's no events sent
... not against a heartbeat (keep alive) feature
Bob: couldn't we just have the impl define a heartbeat event that people can subscribe to?
Tom: its an auto-kick/verify
Bob: network issues are a real concern
Rick: did my reply msg get sent to
the wsra list?
... its the same a http/tcp keep-alive
... its not send at regular intervals - its only when nothing is sent for a subscription for a period of time
Bob: who is the caring party?
subscriber or subscription?
... if its the subscriber then they can do a GetStatus/Verify
Wu: keep-alive is a possible
... keep-alive could reduce the MEPs
Dug: keeping a timer per subscription sounds expensive
tom: yes add it
no objection to adding the missing assertion parameter