Web Services Resource Access Working Group Teleconference -- 01 Jun 2010

<trackbot> Date: 01 June 2010

<scribe> scribe: Dug

<scribe> scribenick: Dug

agenda

<Zakim> dug, you wanted to add a new topic to the agenda

agenda is approved with addition

approving minutes from May 13

approved w/o

new issues

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

reviewer comments

back to 9781

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

WS-I BP WSDL issue

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

9609

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?

<Tom_Rutt> q

<Tom_Rutt> =

<Tom_Rutt> q

<Tom_Rutt> =

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

9613

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9613

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

9610

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

VerifySupported assertion

tom: yes add it

no objection to adding the missing assertion parameter

<asoldano> bye

Adjourned

- DRAFT -

Web Services Resource Access Working Group Teleconference

01 Jun 2010

Attendees

Contents