[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Chatlog of 2013-10-16 f2f
[1:49] Adrian Otto (Rackspace): good morning (London time)[2:50] Gil Pilz (Oracle): The specification of functional interfaces specific to services provided by individual components is out of scope for this document. This is because such interfaces may be quite diverse and differ significantly from platform to platform.
[3:00] Anish Karmarkar: martin's AI: https://www.oasis-open.org/apps/org/workgroup/camp/members/action_item.php?action_item_id=3661
[3:51] Gil Pilz (Oracle): The model of resources manipulated through the interface, in combination with the protocol used to remotely accomplish this, constitutes the self-service PaaS management API.
[3:52] Gil Pilz (Oracle): The API defined by CAMP is made up of resources that represent elements of the underlying system that can be manipulated to affect changes to this system via the HTTP-based protocol.
[3:54] Gil Pilz (Oracle): The CAMP API is made up of resources and a protocol.
[3:54] Gil Pilz (Oracle): The resources represent elements of the underlying system.
[3:54] Gil Pilz (Oracle): These resources can by manipulate via the protocol to affect changes to this underlying system.
[3:55] Gil Pilz (Oracle): The following are some of the main resources in the API.
[4:04] Gil Pilz (Oracle): The CAMP API is made up of resources and a REST protocol. The resource represent elements of the underlying system. These resources can be controlled via the protocol to affect changes to the underlying system. The following are some of the main resources in API.
[4:06] Gil Pilz (Oracle): he CAMP API is made up of resources and a REST protocol. The resources represent elements of the underlying system. The resources can be controlled by the protocol to affect changes to the underlying system. The following are some of the main resources in API.
[4:07] Gil Pilz (Oracle): The CAMP API is made up of resources in a REST protocol. The resources represent elements of the underlying system. The resources can be controlled by the protocol to affect changes to the underlying system. The following are some of the main resources in API.
[4:07] Adrian Otto (Rackspace): affect changes to the underlying system -> change the underlying system
[4:08] Gil Pilz (Oracle): The CAMP API is made up of resources in a REST protocol. The resources represent elements of the underlying system. The resources can be controlled by the protocol to change the underlying system. The following are some of the main resources in API:
[4:11] Adrian Otto (Rackspace): The CAMP API is made up of resources in a REST protocol. The resources represent elements of the underlying system. The protocol enables interaction with the resources. The following are some of the main resources in the API:
[4:36] Gil Pilz (Oracle): The following table is a cross-index of the mandatory, normative statements (i.e. statements containing the keywords "MUST" or "SHALL") that appear in the body of the specification.
[4:39] Gil Pilz (Oracle): The following table is a cross-index of the optional, normative statements (i.e. statements containing the keywords "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" or "OPTIONAL") that appear in the body of the specification.
[4:46] Gil Pilz (Oracle): Consumers SHALL use a value that is unique within the Plan.
[6:35] Adrian Otto (Rackspace): For discussion during today's session of the F2F meeting starting at 3:30 local time:
[6:35] Adrian Otto (Rackspace): https://tools.oasis-open.org/issues/browse/CAMP-79 Proposal in Jira
https://tools.oasis-open.org/issues/browse/CAMP-89 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-90 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-84 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-85 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-86 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-87 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-88 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-92 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-93 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-94 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-96 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-98 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-123 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-102 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-105 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-109 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-113 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-114 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-115 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-116 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-117 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-118 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-128 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-132 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-141 Proposal in Jira[6:47] Adrian Otto (Rackspace): Correction: not all of the above have proposals. These are the ones that *actually* have proposals to consider:
[6:47] Adrian Otto (Rackspace): https://tools.oasis-open.org/issues/browse/CAMP-85 Proposal in Jira
https://tools.oasis-open.org/issues/browse/CAMP-86 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-87 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-89 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-90 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-92 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-93 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-94 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-96 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-128 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-123 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-132 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-141 Proposal in Jira[6:56] Adrian Otto (Rackspace): For discussion: https://tools.oasis-open.org/issues/browse/CAMP-145 with proposal https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51050/camp-spec-v1.1-issue145-v2.doc (In Jira)
[6:59] Adrian Otto (Rackspace): Note: CAMP-141 and CAMP-96 may be closed with no action once CAMP-145 is resolved.
[7:04] Gil Pilz (Oracle): https://tools.oasis-open.org/issues/browse/CAMP-5 - Requirements and Capabilities have been removed https://tools.oasis-open.org/issues/browse/CAMP-22 - Requirement resources have been removed https://tools.oasis-open.org/issues/browse/CAMP-23 - Capability and Template resources have been removed https://tools.oasis-open.org/issues/browse/CAMP-29 - Application Component an Platform Component resources have been merged into Component; Template resources have been removed https://tools.oasis-open.org/issues/browse/CAMP-64 - Requirement resources have been removed https://tools.oasis-open.org/issues/browse/CAMP-77 - Example Database Platform Component appendix has been removed https://tools.oasis-open.org/issues/browse/CAMP-82 - Template resources have been removed https://tools.oasis-open.org/issues/browse/CAMP-141 - offending sentence has been deleted https://tools.oasis-open.org/issues/browse/CAMP-145 - Template resources have been removed
[7:26] Anish Karmarkar66: https://oracleconferencing.webex.com/oracleconferencing/e.php?AT=WMI&EventID=221348072&PW=ef73e679e71f020f53&RT=MiM0
[7:26] Anish Karmarkar66: Meeting starting in 4 minutes [7:29] Anish Karmarkar66: Call-in toll-free number: 1-8666824770 (US) Call-in number: +353-12475650 (Ireland)Show global numbers: https://www.tcconline.com/offSite/OffSiteController.jpf?cc=3005864
[7:30] Adrian Otto (Rackspace): we will be opening the conference bridge in just a moment.
[7:30] Adrian Otto (Rackspace): UK: 0 800 694 8154 [7:31] Tom Rutt (Fujitsu): waiting for leader [7:32] Anish Karmarkar66: enabled now [7:34] Tom Rutt (Fujitsu): host not in meeting in webex [7:35] Anish Karmarkar66: @tom webex is enabled [7:35] Anish Karmarkar66: r u having issues?[7:36] Adrian Otto (Rackspace): https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51055/camp-spec-v1.1-issue145-v3.doc
[7:40] Ashok Malhotra (Oracle): Cannot see Webex... says host not yet joined [7:40] Anish Karmarkar66: @ashok, r u using the URL in the chat? [7:41] Anish Karmarkar66: for webex [7:41] Anish Karmarkar66: i see several folks in webex [7:42] Anish Karmarkar66: Scribe: Anish Karmarkar [7:43] Scribe: Topic: issue 145 [7:43] Ashok Malhotra (Oracle): OK I'm on Webex now[7:43] Scribe: Motion: m:Gil s:Alex resolve issue 145 with the proposal in Jira
[7:44] Scribe: tom: what happened to section 3?[7:44] Scribe: gil: put it back in and removed references to resources that no longer exist
[7:45] Scribe: Gil talks about what is now in section 3 [7:46] Scribe: Need a new issue to figure out we still need section 3[7:46] Scribe: tom: does the plan resource exist before the PDP is posted to the assembly?
[7:47] Scribe: gil: if the provider supports plans then posting a PDP to assemblies results in an assembly and a plan
[7:47] MartinC not that im listenign but we did have an issue to loook at merging 2 and 3 and now with the re-write the teo could condense nicely into a single section
[7:49] Adrian Otto (Rackspace): martin, do you know if that is a PR issue, or a spec issue?
[7:49] Scribe: adrian: safer to open a new issue, if the issue that martin points out is already there we can close it as dup
[7:49] Scribe: no more discussion on the motion [7:50] Scribe: motion approved w/o [7:50] Scribe: RESOLUTION: CAMP 145 is resolved with proposal in JIRA [7:50] Scribe: <applause>[7:50] MartinC: pr issue - one of patrick's - the one where he was confused between the uml class diagram and instance diagrams
[7:51] MartinC holy crap - well done guys!!!! [7:51] Scribe: Topic: issues 5, 22, 23, 29, 64, 77, 82, 141, & 145 [7:52] Scribe: adrian reviews issue 5 [7:53] Scribe: proposals for all the issues are CNA with a reference to 145 [7:53] Scribe: adrian reviews issue 22 [7:53] Scribe: adrian reviews issue 23 [7:53] Scribe: adrian reviews issue 29 [7:53] Scribe: adrian reviews issue 64 [7:53] MartinC im dropping from evesdropping. later guys [7:54] Scribe: adrian reviews issue 77 [7:55] Scribe: adrian reviews issue 82 [7:55] Scribe: adrian reviews issue 141 [7:56] Scribe: adrian reviews issue 145 [7:56] Scribe: adrian reviews issue 145[7:57] Scribe: Motion: m:Gil s:Ashok Close issues 5, 22, 23, 29, 64, 77, 82, and 141 with no action as they are resolved by resolution of issue 145
[7:57] Scribe: no discussion [7:57] Scribe: motion approved w/o[7:58] Scribe: RESOLUTION: Issues 5, 22, 23, 29, 64, 77, 82, and 141 are closed with no action (resolved by issue 145)
[7:59] Scribe: Topic: issues 85, 86, 87, 89, 90, 92, 93, 94, 96, 128, 123, 132, 141
[8:00] Scribe: Adrian discusses each issue and its proposal [8:04] Tom Rutt (Fujitsu): from YAML 1.1 spec Copyright 2001-2008 Oren Ben-Kiki, Clark Evans, Ingy dt Net This document may be freely copied, provided it is not modified.[8:05] Scribe: mark: need to worry about requirements of taking our spec to ISO
[8:05] Scribe: mark: adding it to our appendix would also be an option[8:06] Scribe: mark: if we could enlist folks like Tim Bray/MarkN to move this to IETF
[8:06] Gil Pilz (Oracle): Would adding it to our appendix make us responsible for it?
[8:06] Gil Pilz (Oracle): If not, how does that help anyone?[8:06] Scribe: ACTION: Mark to engage with Tim Bray/MarkN to see if YAML 1.1 can be moved to IETF
[8:07] Scribe: tom: note that the copyright stmt allows copying [8:07] Scribe: tom: note that the copyright stmt allows copying [8:07] Scribe: tom: note that the copyright stmt allows copying[8:07] Scribe: ... wrt ISO there are ways around this, such as reference explanatory note
[8:08] Mark Carlson: AI: Mark to contact @tbray, @mnot to see if they can champion YAML in IETF
[8:10] Adrian Otto (Rackspace) lowered your hand[8:10] Scribe: anish: taking the spec thru an org like IETF would result in the spec itself changing
[8:10] Scribe: ashok: do we really feel that strongly on YAML? [8:11] Scribe: adrian: the move to use yaml is to help devs and human beings [8:11] Scribe: ... for example json doesn't allow comments [8:12] Scribe: ... we are trying to track implementers preferences [8:12] Scribe: ... we are trying to track implementers preferences[8:12] Mark Carlson: https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-03.html - "This revision does not change any of the rules of the specification; all texts which were legal JSON remain so, and none which were not JSON become JSON. The revision's goal is to fix the errata and highlight practices which can lead to interoperability problems."
[8:12] Mark Carlson: https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-03.html - "This revision does not change any of the rules of the specification; all texts which were legal JSON remain so, and none which were not JSON become JSON. The revision's goal is to fix the errata and highlight practices which can lead to interoperability problems."
[8:12] Scribe: ... if OASIS comes back saying no way we can host/copy it, we'll have to reconsider
[8:14] Scribe: Mark: example of JSON proposal by tim bray that does not want to change anything. Same will be true for YAML
[8:14] Scribe: anish: keep this issue out of the block motion, as we don't know what oasis' answer will be
[8:20] Ashok Malhotra (Oracle): +1 to Anish [8:20] Adrian Otto (Rackspace) lowered your hand [8:21] Scribe: anish: add security consideration section to the spec [8:22] Scribe: adrian walks thru proposal for issue 89 [8:22] Scribe: changed 'roles' to 'actors' [8:23] Scribe: changed section 1.6 Terminology [8:23] Scribe: included definition for CAMP provider and Consumer [8:25] Scribe: Adrian walks thru proposal for issue 90 [8:25] Scribe: 90 is addressed by issue 99 [8:25] Scribe: Adrian walks thru proposal for issue 92 [8:26] Scribe: editorial issue [8:27] Scribe: Adrian walks thru proposal for issue 93 [8:28] Scribe: Adrian walks thru proposal for issue 94 [8:29] Scribe: Adrian walks thru proposal for issue 96[8:31] Scribe: motion m:Gil s:Anish Move to close issue 96 with no action as it is already resolved by issue 145 resolution
[8:31] Scribe: no discussion [8:31] Scribe: motion approved w/o[8:31] Scribe: RESOLUTION: Issue 96 closed with no action as it is already resolved by resolution of issue 145
[8:32] Scribe: Adiran discusses issue 128[8:35] Scribe: adrian: this is not ready for resolution. we don't yet address the media types issue
[8:35] Scribe: Adrian walks thru proposal for issue 123 [8:38] Scribe: Adrian walks thru proposal for issue 132[8:41] Scribe: Motion: m:Gil s:Anish close issue 132 to close it with no action
[8:42] Scribe: no discussion [8:42] Scribe: motion approved w/o [8:42] Scribe: RESOLUTION: issue 132 is CNA [8:42] Scribe: Adrian walks thru proposal for issue 141 [8:43] Scribe: Adrian: already processed 141, we are done with this[8:45] Adrian Otto (Rackspace): Completed review of: CAMP-85, CAMP-87, CAMP-89, CAMP-90, CAMP-92, CAMP-93, CAMP-94, CAMP-123
[8:45] Scribe: motion: m:Gil s:Anish resolve CAMP-85, CAMP-87, CAMP-89, CAMP-90, CAMP-92, CAMP-93, CAMP-94, CAMP-123 with proposal in Jira
[8:46] Scribe: no discussion [8:46] Scribe: motion approved w/o[8:46] Scribe: RESOLUTION: CAMP-85, CAMP-87, CAMP-89, CAMP-90, CAMP-92, CAMP-93, CAMP-94, CAMP-123 resolved with proposals in Jira
[8:47] Gil Pilz (Oracle): https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50034/CAMP%20sched%202013-07-19.pdf
[8:48] Scribe: Topic: Schedule [8:51] Scribe: anish: we are already late by 2 weeks[8:54] Scribe: ... we have to let Jacques take the changes and accommodate the test suite
[8:54] Scribe: ... we also have to deal with Jacques challenges [8:54] Scribe: ... no major issues left [8:55] Scribe: ... perhaps move it by 3 weeks[8:56] Scribe: so 1st PR end of 1st week of November; start of CS ballot end of 1st week of december
[8:56] Scribe: no one objects [8:57] Scribe: Topic: raising the bar on new issues [8:58] Ashok Malhotra (Oracle): I thought it was 2/3[8:58] Scribe: "Special Majority Vote" is a TC vote in which at least 2/3 (two thirds) of the Voting Members vote "yes" and no more than 1/4 (one fourth) of the Voting Members vote "no". These numbers are based on the total number of Voting Members, regardless of the number of Voting Members present in the meeting. Abstentions are not counted. For example, in a TC in which there are 30 Voting Members, at least 20 Voting Members must vote "yes" for a motion to pass; but if 8 or more vote "no" then the motion fails. All Special Majority Votes must be conducted via electronic ballot by the OASIS TC Administrator.
[9:00] Adrian Otto (Rackspace): 2/3 of voting members present [9:00] Scribe: 2/3 of voting members present & voting[9:02] Scribe: Motion: m:Gil s:Alex Moves to create a standing rule to require 2/3 majority of voting members present and voting to open new issues against CAMP 1.1
[9:03] Scribe: anish: reminder that PR is an escape hatch [9:03] Scribe: no discussion [9:03] Scribe: motion approved w/o[9:04] Scribe: RESOLUTION: new standing rule to require 2/3 majority of voting members present and voting to open new issues against CAMP 1.1
[9:05] Scribe: Topic: new issue 146 [9:05] Scribe: deferred till next call[9:06] Scribe: Topic: types, superclass, subclass, inheritance and substituitability
[9:06] Gil Pilz (Oracle): https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50959/camp-spec-v1.1-issue-44.doc
[9:06] Scribe: related to issue CAMP-44 [9:07] Scribe: Alex argues for multiple-interfaces [9:09] Scribe: issue of diamond inheritence [9:11] Scribe: s/multiple-interfaces/multiple-inheritance/ [9:11] Scribe: Gil argues for single-inheritance[9:12] Scribe: Alex: if you have cowboy-artist then its draw operation must do what draw of cowboy *and* draw of artist says it does simultaneously. Otherwise it is lying
[9:15] Scribe: Derek: agree with Alex. There are ways to address the ambiguity problems
[9:15] Scribe: Tom: there has to be rules about common attributes. We could say that we disallow it if there are common names
[9:16] Scribe: ... This is complicating this. We have to justify adding complicated rules
[9:17] Tom Rutt (Fujitsu): s/if there are common names/if there are common attribute names with different types/
[9:17] Scribe: ashok: this is hard and complicated. We could spend hours on this. I have a thought about how we could do this quickly -- various programming languages/disciplines have worked this out. What we could do is -- we are going to do exactly like "so-and-so" which address all the difficult issues that come up. Fine a scheme that we are happy with which is well worked out and copy that.
[9:17] Scribe: Adrian: do you have any in mind? [9:17] Scribe: Ashok: no. but can research this[9:18] Scribe: Gil: we are making comparison to programming languages. But we don't have a compiler. All we got is a type definition.
[9:18] Scribe: ... it is a definition of particular resource type[9:19] Scribe: ... the mechanisms to get multiple inheritance to work escapes me
[9:19] Scribe: ... no existing implementations to worry about [9:19] Scribe: ... understand the usecases and desire. [9:20] Scribe: ... we should postpone this till the next version [9:20] Scribe: Alex: it is actually pretty easy to implement [9:20] Scribe: ... i would be OK with leaving it as is[9:21] Scribe: ... but if we were going to have inheritance then it would drive me bonkers if multiple-inheritance did not exist
[9:22] Scribe: Derek: was thinking of proposing a syntax for this. An array might just do it.
[9:22] Scribe: Gil: our type definitions do not say anything about operation.
[9:23] Scribe: Alex: would be fine with it. [9:23] Scribe: Adrian: would be an interesting extension[9:24] Scribe: ashok: what happens if two attributes have the same name and they don't match
[9:25] Scribe: alex: in some cases it would be an error if it is not possible
[9:25] Tom Rutt (Fujitsu): OMG CORBA has a set of rules for interface inheritance see clause 7.8.5 in http://www.omg.org/spec/CORBA/3.1.1/Interfaces/PDF/
[9:26] Scribe: Lots of freeform discussion between Alex and Gil[9:28] Scribe: anish: what would happen if we don't say anything about inheritance. Would that make the spec inconsistent. Concerned about introducing such a feature so late
[9:30] Alex Heneveld: @Tom - looking at that section. it seems quite simple.
[9:32] Scribe: Gil: it is going to result in something equally complex[9:34] Scribe: Derek: we all have a meta-model in our mind. And these things result in bringing forward mismatches. The spec is not going to have a meta-model. We should perhaps just figure out what we want to express.
[9:34] Scribe: ... would prefer to leave it out. But if we can't then just bite the bullet and do it
[9:35] Scribe: Alex: we got a lot of attributes and the only way we know it's there is thru the type system
[9:35] Scribe: ... if we can find a simple solution quickly we should put it in. But if we can't we can just leave it out
[9:36] Scribe: Adrian: if we have an array for inheritance then implementations can decide whether to use inheritance
[9:37] Tom Rutt (Fujitsu): @alex, the corba rules do not allow the directly inherited interfaces to have attributes with common names. so draw in cowboy and draw in artist would not be allowed to be multiple inherited in cowboy artist, but the diamond repeats of attributes are allowed because they are the same attribute
[9:38] Scribe: <Open ended discussion not scribed> [9:39] Scribe: Topic: straggler role [9:40] Scribe: anish: thanks to fujitsu for hosting the f2f. Great network[9:41] Scribe: Adrian: martin not available next week. Unless we hear from martin I'll be your pro-tem chair next week
[9:42] Scribe: Meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]