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
approved w/o
9871: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9781
oops
9781: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9781
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
still alive
... 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
section
... 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?
Bob: TBD
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9609
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
this
... 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
Bob: reaction?
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?
Rick: yes
Ram: would prefer to have two
independent verbs
... 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
change?
... 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?
Dug: yes
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.
<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0053.html
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
... first
<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
Enum?
... 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?
... probably
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
d) CWNA
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].
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9613
q
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 :-)
<Bob> 11
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
statement
... 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
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9610
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
solution
... 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
Adjourned