[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: http://webconf.soaphub.org/conf/room/sca-bindings-TC 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 Introductions 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 http://www.oasis-open.org/committees/download.php/33757/SCA%20Bindings%20minutes%202009-07-30.doc 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: http://lists.oasis-open.org/archives/sca-bindings-comment/200908/msg00000.html 6. Open issue discussion One open issue, one deferred: http://www.osoa.org/jira/browse/BINDINGS-85 non_Persistent Should be an Intent Raiser: Ashok Malhotra, owner: Unassigned Priority: Unassigned Status: awaiting action 20090730-1 http://www.osoa.org/jira/browse/BINDINGS-60 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 http://www.oasis-open.org/committees/download.php/30138/sca-binding-http-1.1-spec-wd01.doc http://www.oasis-open.org/committees/download.php/30139/sca-binding-http-1.1-spec-wd01.pdf 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]