OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Raw chat notes for 2009-08-20

Here's my capture of the raw chat notes from today:

Simon Holdsworth: SCA Bindings TC weekly telecon 

Chat room: 


Audio conference: 

Meeting Number: * 913929 * (press * before and after the digits) 

Phone numbers: 

Austria = Vienna 026822056419 
Belgium = Brussels 022901709 
China = Beijing 01052237296 
Czech Republic = Prague 239014054 
Denmark = Copenhagen 32714982 
France = Lyon 0426840196 Marseille 0488915310 Paris 0170994364 
France TollFree = 0800944795 
Germany = Berlin 030726167296 Dusseldorf 021154073845 Frankfurt 069710445413 Hamburg 040809020620 Munich 089244432767 Stuttgart 0711490813212 
Germany TollFree = 08006646304 
India = Mumbai 02261501417 
Ireland = Dublin 014367612 
Italy = Milan 0230413007 Rome 06452108288 Turin 01121792100 
Japan = Tokyo 0357675037 
Netherlands = Amsterdam 0207965349 
Poland Toll-free = 008001213648 
Portugal Toll Free = 800782079 
Russia = Moscow 84999222481 
Russia Toll Free = 81080022074011 
South Africa Toll-free = 0800982617 
Spain = Barcelona 934923140 Madrid 917889793 
Sweden = Stockholm 0850520404 
Switzerland = Geneva 0225927186 
UAE Toll-free = 8000440387 
UK = Birmingham 01212604587 London 02071542988 Manchester 01612500379 
UK Toll Free = 08003581667 
USA = 19543344789 
USA & Canada Toll Free = 18665289390
Simon Holdsworth: Agenda
Simon Holdsworth: 1. Opening 

Roll call 
Scribe assignment 

Top of the scribe list: 
Khanderao Kand Oracle Corporation 
Plamen Pavlov SAP AG 
Simon Nash Individual 
Piotr Przybylski IBM 
Eric Johnson TIBCO Software Inc. 
Anish Karmarkar Oracle Corporation 
David Booz IBM 
Martin Chapman Oracle Corporation 
Tom Rutt Fujitsu Limited 
Bryan Aupperle IBM 

Agenda bashing 

2. Approval of the minutes from 30th July 


3. Actions 

20090211-4 [General] Write up HTTP binding use cases 
20090709-2 [Editors] Update the schema appendix title to include 1.1 
20090730-1 [Simon Holdsworth] Send mail explaining his position on issue BINDINGS-85 

4. New Issues 

no new issues 

5. PRD status 

Update on status of Public Review 

One comment so far: 


6. Open issue discussion 

One open issue, one deferred: 

non_Persistent Should be an Intent 
Raiser: Ashok Malhotra, owner: Unassigned 
Priority: Unassigned 
Status: awaiting action 20090730-1 

JMS Default wire format insufficient to cover real world usage 
Raiser: Mike Edwards, owner: Simon Holdsworth 
Priority: 3 (deferred) 
Status: outline proposal in issue 

7. Test Assertions/Test cases 

Status of TA documents 

JMS - initial draft, some review 
WS - no progress 
JCA - no progress 

8. HTTP binding 

Assess TC's opinions on proceeding with the HTTP binding 



9. AOB
Dave Booz: Eric, I submitted a new issue yesterday, any chance you could get it logged for this call?
Eric Johnson: Scribe: Eric
Eric Johnson: Topic: Reviewing agenda
Eric Johnson: One new issue has arisen.
Eric Johnson: No comments on agenda.
Eric Johnson: Topic: Approval of the minutes
Eric Johnson: No objections to approving minutes.  Minutes are approved.
Eric Johnson: Topic: Action items
Eric Johnson: 20090730-1 - completed.
Eric Johnson: No progress on the other two issues.
Eric Johnson: s/issues/actions/
Simon Holdsworth: New issue: http://www.osoa.org/jira/browse/BINDINGS-86
Eric Johnson: Topic: New issues
Simon Holdsworth: Issue title: SOAP intent qualifiers have to be renamed
Mike Edwards: For those who understand soccer - this is a red card from the Policy TC
anish: let's not be harsh -- its yellow. bindings won't be ejected from the game
Eric Johnson: Mike Edwards: A fine issue
Eric Johnson: ... pretty well a shoo-in
Eric Johnson: Dave B moves, Mike E seconds, to open issue 86
anish can we resolve this? seems simple and non-controversial
Mike Edwards: ++1
Eric Johnson: No objections to unanimous consent.  Motion passes.
Eric Johnson: (Dave B Reviewing proposal in the issue.)
Eric Johnson: Mike E: The proposal is the one that policy went for, so another direction would not be wise.
Eric Johnson: Anish: I move to resolve issue 86 with the proposal in Jira
Eric Johnson: Brian: 2nds
Martin C what a way to squeak
Bryan Aupperle: s/Brian/Bryan/
Eric Johnson: No objections to unanimous consent. Motion passes.
Eric Johnson: (apologies to Bryan)
Eric Johnson: Topic: PRD status
Eric Johnson: Simon H: Thanks to Anish for staying on top of issues.  So far, one comment.
Eric Johnson: Anish: Mike Champion is proposing that the protocol should be handled in a working group.  Not clear that there is a web services WG within OASIS that would be appropriate.
Eric Johnson: Mike E: What we've really done is a profile of a combination of specifications.  It is within SCA so that we could have callbacks working.  Primary goal is to have this working within SCA.
Eric Johnson: Simon H: Need to draft a response.  Who is prepared to draft a response for the TC to review?
Eric Johnson: Anish: Shouldn't we start by filing a PR issue for this?
Eric Johnson: Mike E: Should be raised as an issue for tracking purposes.
Eric Johnson: Simon H: Is every comment turned into an issue, or is it something we review to figure out how to respond, editorial vs. issue, for example.
Eric Johnson: Anish: We have to track responses.
Eric Johnson: Martin: Anish is correct.
Eric Johnson: Bryan: In C/C++ we got some PR comments that turned into multiple issues.  Certainly other TCs have turned a PR comment into *at least one* issue.
anish IIRC, eric has already created PR components
anish something equivalent to that
Eric Johnson: Martin: Open issues when they arrive on the mailing list, associate with a "pr" component.
Eric Johnson: Eric: I will send emails to the TC mailing list when I log issues received.
Eric Johnson: Topic: Open issue discussion
Eric Johnson: Subtopic: Issue 85
Eric Johnson: I looked around the minutes and the mailing list, and didn't see anyone wanting to remove "delivery mode" attribute.
Eric Johnson: Simon H:  I looked around the minutes and the mailing list, and didn't see anyone wanting to remove "delivery mode" attribute.
Eric Johnson: ... if we drop the delivery mode attribute, we can specify at the binding level and the operation level.  Don't believe we can apply intents at an operation level.
Eric Johnson: Mike E: Not true - cannot do it in the SCDL, but can do it in the interface definition files.
Eric Johnson: Ashok: In WSDL, for example?
Eric Johnson: Mike E: Yes.  In principle it is possible.
Eric Johnson: ... would not encourage people to do it, but the facilities are there.
Eric Johnson: Simon H: Cannot think of any case where you want to set this, but not also set "at most once" or "at least once".  Might be confusing if there are some properties that you can set via attributes, and some via intents.
Eric Johnson: ... We might want to look at the other headers we provide - should they be intents?  But how do you turn "time to live" into an intent?
Eric Johnson: Dave B: We could invent a policy language that specifies a value.
Eric Johnson: Simon H: You would define a set of names that associate name to specific values?
Eric Johnson: Ashok: No - what you would do is spell out a WS-Policy assertion.  That would have as a parameter the duration.  That would be easier.
Eric Johnson: Dave B: Both are much harder than just putting the value on the binding.
Eric Johnson: Anish: Why is the resolution for 48 saying that if it is configured for non-persistent, it cannot be at least once?
Eric Johnson: Simon H: It was my belief that you cannot satisfy at least once without persistence?
Eric Johnson: Anish: Not true - if there is no failure, then you can see to having the message delivery
Eric Johnson: Ashok: Nope - you require persistence.  You can fail at the other end.
Eric Johnson: Anish: All these messaging guarantees are conditional.  Within these parameters, we provide you the guarantee.  It is possible to do this in a non-persistent mode...
Eric Johnson: Ashok: Question: why are we speaking about a mechanism, rather than a feature.  We ought to speak about a feature, like "at least once", rather than how that is realized.
Eric Johnson: Anish: Whether JMS is configured in non-persistent mode.  What happens when we have intents that require a particular configuration for a particular implementation?
Eric Johnson: ... don't think the sentence, as written, for issue 48 is actually applicable in all circumstances.  What should the runtime do if a configuration is inconsistent with intents.
Eric Johnson: Simon H: Assumption made as basis of this text.  Making an assumption about how the intent is implemented.
Eric Johnson: Anish: Making a general comment about messaging systems.  Don't necessarily require "persistence" per-se, for example could use process replication.
Eric Johnson: Simon H: Certainly true that an application need not rely on JMS persistence to support the intents.  We might relax the wording, to indicate that if the implementation cannot satisfy an intent for a given combination of configuration and intents, it should raise an error.
Eric Johnson: ... separate from the question of whether or not we remove the attribute
Eric Johnson: Mike E: Does persistence have any other implications or meanings beyond implementing an intent "at least once".  If there are other implications, we should think about it a different way.
Eric Johnson: ... How might the intents actually be configured?  Not as parameters on the bindings themselves, but as the policy sets that are applied to the binding.
Eric Johnson: Anish: Want to qualify my comment.  If it turns out that everyone out there requires persistence to satisfy these guarantees, then it might be a fine thing to have the current restriction.
Eric Johnson: Simon H: Do we want a new intent?
Eric Johnson: Ashok: No - your argument on that is convincing, Simon.
Eric Johnson: Simon H: Then we're simply talking about removing the delivery mode attribute, or we retain it and adjust the text that is there.
Eric Johnson: Ashok: We should remove it.  Possibly a different issue related to conflict between intent and configuration parameters.
Eric Johnson: Bryan: Does that apply across bindings, or is that a policy issue?
Eric Johnson: Ashok: Applies across bindings, don't know if it is a policy issue.
Eric Johnson: Eric: There's no expectation on the policy side of directly using the elements in the JMS binding.
Eric Johnson: Dave B: Correct.  You need to specify a policy language that that is what is used.  Neither policy defines that nor does the TC do that.
Eric Johnson: Mike E: Is it a wise thing for the TC to define this for JMS?  We have one for WS, via WS-Policy.  Wary about defining one for JMS.  It is difficult, really.  Ideally we wouldn't use the binding templates at all.  Challenge of building a new policy language might be more than we want to entertain.
Eric Johnson: Ashok: Not really speaking about a new policy language here.  All that is required is to specify one or two WS-PolicyAssertions.  It is fairly simple to do.
Eric Johnson: ... Lots of people are doing this.
Eric Johnson: Mike E: We could get rid of the mechanism of having templates, and push that into policy sets.
Eric Johnson: Dave: What you're calling a policy assertion, I call a policy language.
Eric Johnson: ... anyone who defines a new assertion is defining a language.
Eric Johnson: Ashok: "New Policy Language" sounds heavy weight.
Eric Johnson: Simon H: We don't appear to be in a position to resolve the issue right now.  Looks like the direction we're headed is to remove the attribute.
Eric Johnson: Action: Simon H. to propose a resolution to BINDINGS-85.
Eric Johnson: Action: Simon H to look at the templating mechanism with respect to policy.
Eric Johnson: Topic: AOB?
Eric Johnson: Next meeting next week.  Meeting adjourned.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]