[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes October 2013 F2F
Minutes of the CAMP F2F, 14 - 16th October 2013 Hosted by Fujitsu, UK Meeting Attendees: Oracle Mark Carlson Voting Member Oracle Martin Chapman Chair Fujitsu Limited Jacques Durand Voting Member Cloudsoft Corporation Limited Alex Heneveld Voting Member Oracle Anish Karmarkar Voting Member Oracle Ashok Malhotra Voting Member Rackspace Hosting, Inc. Adrian Otto Secretary Vnomic Derek Palma Voting Member Oracle Gilbert Pilz Voting Member Fujitsu Limited Tom Rutt Voting Member Intro: Scribes: Adrian (Monday session), Jacques (Tuesday session), Anish (Wednesday session) [Adrian Scribing] Agenda: Three two hour sessions held over three days (15:30 - 17:30) . GOAL of the F2F: Ensure we have directions/resolutions for all P1s and all PR comments Agenda based on 1) the posted agenda and 2) proposals as a result of discussion during the informal parts of the gathering. Under issues discussion lead with CAMP-145 https://tools.oasis-open.org/issues/browse/CAMP-145 No opposition raised to proposed Agenda Roll: Attendees listed above, 10 of 14 voting members (71%) Meeting is quorate. Minutes: 9th October 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201310/msg00069.html Motion: m=Gil s=Anish no objections, Minutes accepted Action Items: Jacques Durand: Coordinate Editing team meeting to discuss the challenges document referenced in CAMP-83. TBD Gilbert Pilz: Get input from Martin (email) on what publications he thinks we should release between our PRs. CLOSED - Overtaken by events Topic: Administrivia Current open issues: 82 in total; 7 P1, 68 P2, 7 P3. Topic: Editors Update WD25 released: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51007/camp-spec-v1.1-wd25.doc Topic: New Issues no new issues from last week to process Issue Discussion: CAMP-145 https://tools.oasis-open.org/issues/browse/CAMP-145 Gil presents a rewrite based on a discussion about simplification: removal of templates, collapsing app and platform components, and bringing the resource model in line with the pdp. https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51025/camp-spec-v1.1-RMR.doc Platform Resource is changed links from Platform are adjusted to URIs of collections of resources rather than arrays of resources assembliesUri, servicesUri, and plansUri are the key differences Assemblies: Collection of Assembly Resources Assembly Resources are mostly the same, but they refer to components rather than platformComponents Services is a collection of Service Resources Plans is a collection of Plan resources A Plan resource is an optional expression of a DP, in JSON rather than YAML If you POST a Plan to an Assemblies resource, an Assembly results If you POST a Plan to a Plans resource, a Plan results If you POST to a Plan, you get an Assembly Components is a collection of Component resources Component resources have a "relatedComponents" attribute so you can generate a hierarchy of components (parents, children, etc.) artifact refers to an Artifact from a Plan service refers to a Service (formerly known as PCT) Issues 29, 23, 5, 22, 37, 64, 66, 74, 82 all addressed by this proposal. Alignment of terminology is most of the proposed approach Making the creation of an Assembly into a one step process is an additional feature of the contemplated Platform Ashok: When do the components go away when the Assembly is acted upon by a DELETE request? Martin: it would be possible to delete an Assembly and all related Components without impairing other Assemblies Alex: Platform implementers can decide when Containers are shared, if at all Alex: suggests that observing what implementations do should guide future spec work on this. Try not to over-specify this. Alex Heneveld: (& this was an issue pre-refactoring, if anything this simplifies discussion on the issue) Gil: Simplifying the spec to have fewer component types is a significant reduction in complexity Gil: Section 4 does not change Gil: Section 6 does not change Gil: Extensions and metadata does not change. Only the resource model is adjusted. Gil: Section 1.3 can be adjusted to show a more simple workflow to more closely track how today's PaaS systems work (go directly to a running Application in a one-step process) Gil: The original two-step process is also possible by using a new feature (Plans) Tom Rutt (Fujitsu): leave separate URI resources for each type of container Additional discussion: Adrian, Alex, Gil, Martin, Tom touched on backpointers touched on types, and possible consolidation for collections Justification for this work: Adoption >> Window of Opportunity >> Interop + Portability helps us strike a balance of Adoption and WoO Tom: text about DP generated comment(s), there may be some editorial work to address that. words "node" and "type" may not be used consistently we will address this during the F2F within the scope of issue triage. Topic: Triage Issues, identifying each issue flagged for TC discussion https://tools.oasis-open.org/issues/browse/CAMP-98 discuss -editorial sections 2 and 3 could be merged. Gil: Yes, we can merge them. Alex: instance diagrams are not the same as the type diagrams Tom: We do need two different diagrams, but we could decide to just describe them with words, and not use a diagram. Martin: Suggests we revisit this after our resource refactoring effort https://tools.oasis-open.org/issues/browse/CAMP-99 discuss (with 98 maybe merge section 2 and 3) - editorial Martin: Gil's proposal for CAMP-83 would address this. Gil: confirms, yes. Looking at CAMP-83 proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50879/camp-spec-v1.1-wd20-r1-NewNormTags-f3.doc text in section 1.6 may resolve CAMP-99 + a minor editorial adjustment to the sentence about 'These tables appear in Appendix C, "Normative Statements"' Tom Rutt (Fujitsu): I agree with adding the sentenced "all examples are informative" Tom: Perhaps the table of "Normative Statements" are actually "Conformance Statements"? Jacques: They are Normative Statements, not Conformance Statements we can add "Examples are all informative, not normative" Martin is updating CAMP-99 with an excerpt from the proposal for CAMP-83 to address the normative statement concern. Martin: "The statements that use these keywords have been highlighted as per this sentence, and each such statement has been given a unique tag in the following manner: [EX-00] For convenience these statements have been tabulated and cross-indexed by their tags and appear in Appendix C, Normative Statements. All examples in this document are non-normative." We will add "This section is informative." to the start of Sections 2 and 3. MartinC1: mark section 2 and 3 as being informative. Tom Rutt (Fujitsu): rfc 2119 is about marking "requirements" Key words for use in RFCs to Indicate Requirement Levels CAMP-99 updated with Martin's proposal MOTION: m=Adrian s=Gil to resolve CAMP-99 with a direction to the editors to make changes outlined by Martin's proposal added to CAMP-99 as a comment. Proposal: In section 1.6, terminology, add the following text after the 2nd para: The normative statements that use these keywords have been highlighted as per this sentence, and each such statement has been given a unique tag in the following manner: [EX-00] [{note to editor highlight the sentence} For convenience these statements have been tabulated and cross-indexed by their tags and appear in Appendix C, Normative Statements. All examples and notes in this document are informative. Unless marked otherwise text in this specification is normative. In addition add the following text as the first line of section 2 and section 3. "This section is informative." Editors discretion to mark other sections/appendices as informative. No discussion. No objections. Motion passed. https://tools.oasis-open.org/issues/browse/CAMP-102 discuss - technical MOTION: m=Adrian s=Gil to close CAMP-100 with no action in accordance with resolution to CAMP-99. No discussion. No objections. Motion passes. https://tools.oasis-open.org/issues/browse/CAMP-101 Tom Rutt (Fujitsu): could close as accommodated by resolution to 99 https://tools.oasis-open.org/issues/browse/CAMP-109 discuss - editorial https://tools.oasis-open.org/issues/browse/CAMP-113 The value of this node expresses the version of the CAMP specification to which the Deployment Plan conforms. This value SHALL be the Specification Version String of the CAMP specification to which this Deployment Plan conforms. The value of this node SHALL be "CAMP 1.1" as defined in Section XX [PDP-18] The value of this node expresses the version of the CAMP specification to which the Deployment Plan conforms. This value SHALL be the Specification Version String of the CAMP specification to which this Deployment Plan conforms. [PDP-18] NOTE: The value of this node SHALL be "CAMP 1.1" as defined in Section XX Tom Rutt (Fujitsu): we need to wait to see if 1.2 is backwards compatible to 1.1 Jacques (Fujitsu)1: just remove PDP-18 Tom Rutt (Fujitsu): perhaps this campVersion node should be a sequence node, that way a dp maker could state which versions they are compatible with. They may only use the Cross-section of features from both versions Tom Rutt (Fujitsu): futureproof the dp syntax Tom Rutt (Fujitsu): the array has the versions that this dp conforms to. They would only be able to put two values in if they conform to both versions meeting is in recess until tomorrow [Jacques scribing] Meeting restarts. topic: triage of PR issues, recap chair: for 3/4 we have proposed resolutions. Adrian: we have 11 ready to close. Adrian Otto (Rackspace): I will (in a moment) move to close CAMP-91, CAMP-95, CAMP-97, CAMP-101, CAMP-103, CAMP-104, CAMP-106, CAMP-107, CAMP=108, CAMP-129, and CAMP-130 with no action, as each of these issues has been satisfied by the resolution of CAMP-99. Adrian: need more time to review? all on this list are obviated by CAMP-99 discussed yesterday MOTION: Adrian: to close all above issues: CAMP-91, CAMP-95, CAMP-97, CAMP-101, CAMP-103, CAMP-104, CAMP-106, CAMP-107, CAMP-108, CAMP-129, and CAMP-130 with no action, Sec: Tom ... no discuss, no object. UNAN. chair: we present proposal for CAMP-145 Issue 145: Gil has a more concrete proposal: Gil: major refactoring of our resource model is in order (addressing number of issues and feedback) Gil: section 1.3 illustrates key examples of main usage scenario ... proposed: to simplify the creation of an app - in 1 operation (if desired) ... use a generic "Component" resource, no AssemblyTemplate anymore. ... introduce Services (as replacement for PCTs) ... Plan (replaces AssemblyTemplate somehow) ... Artifacts are inert packages, migration-ready, as opposed to Components that are dynamically used Mark: Fig 2-7 needs update (Assemblies missing) Gil: need to harmonize diagrams. Alex has great ideas about this. Gil: we are not trying to approve 145 today Tom: this is simpler chair: section 3 needs be rewritten ... at least partially Gil: working with "Plans": the "resource" view of a Plan must have same data or less than the file content/view ... so Service ref (href) needs be in the Plan file ... we don't have Requirements anymore (nor capability) ... platform content consequently changed. Anish: URI --> URL Ashok: relationship Assembly and Plan? Gil: relationship visible at instance level ... planURI in Assembly Tom Rutt (Fujitsu): { "uri": URI, "name": String, "type": "component", "description": String ?, "tags": String[] ?, "representationSkew": String ?, "assembly": Link, "artifact": URI ?, "service": URI ?, "status": String, "relatedComponents": Link[] ?, "operationsUri": URI ?, "sensorsUri": URI ? } Tom: Plan without common attributes? Gil: they are in YAML format. Gil: we have lost some functionality in the process: can't get back the PDP anymore from Provider (no PDP URI in the Plan) Alex: in favor of taking this as is. Just file a new issue for additional features like this linkage. Gil: support for Plan is advertised in metadata (an extension resource "CAMP-Plans-Extension") Adrian: many of CAMP systems have built-in features. Annoying. A singular interface (CAMP extensions) better for advertising this. ... Note: may exist alternatives to advertise Plan support Gil: deploying an app not same as registering a Plan. Another issue is: how to stop vs delete... chair: comments? Adrian: we should thank Gil. The proposal reduces size of spec, would help adoption. ... (others chime in) Gil Pilz (Oracle): :-$ Alex: well done. Good we get such a consensus on this. chair: needs still the blessing of the TC for that *direction* MOTION: Adrian: that the TC recognizes the current proposal for 145 as directional, for the editors to work further on this issue. second: Gil ... no discussion, no objection. Pass UNAN. Back to triaging: Adrian Otto (Rackspace): https://tools.oasis-open.org/issues/browse/CAMP-121 Proposal in Jira (close-no-action) https://tools.oasis-open.org/issues/browse/CAMP-124 Proposal in Jira (close-no-action) https://tools.oasis-open.org/issues/browse/CAMP-133 Proposal in Jira (close-no-action) https://tools.oasis-open.org/issues/browse/CAMP-134 Proposal in Jira (close-no-action) https://tools.oasis-open.org/issues/browse/CAMP-139 Proposal in Jira (close-no-action) https://tools.oasis-open.org/issues/browse/CAMP-140 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-138 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-137 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-136 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-135 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-131 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-127 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-125 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-122 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-120 Proposal in Jira https://tools.oasis-open.org/issues/browse/CAMP-119 Proposal in Jira Adrian: proposed resolutions for group ... ... first 6 close w no action, the remainder have proposals in JIRA issue: 121 https://tools.oasis-open.org/issues/browse/CAMP-121 MOTION; Adrian: to clowse w proposal in JIRA. Tom 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-124 https://tools.oasis-open.org/issues/browse/CAMP-124 MOTION; Adrian: to close w proposal in JIRA. Anish 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-133 https://tools.oasis-open.org/issues/browse/CAMP-133 MOTION; Adrian: to close w proposal in JIRA. Jacques 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-134 https://tools.oasis-open.org/issues/browse/CAMP-134 MOTION; Adrian: to close w proposal in JIRA. Gil 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-139 https://tools.oasis-open.org/issues/browse/CAMP-139 MOTION; Adrian: to close w proposal in JIRA. Jacques 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-140 https://tools.oasis-open.org/issues/browse/CAMP-140 MOTION; Adrian: to close as subsumed by 145. Gil 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-138 https://tools.oasis-open.org/issues/browse/CAMP-138 MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-137 https://tools.oasis-open.org/issues/browse/CAMP-137 OTION; Adrian: to resolve w proposal in JIRA. Gil 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-136 https://tools.oasis-open.org/issues/browse/CAMP-136 MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-135 https://tools.oasis-open.org/issues/browse/CAMP-135 MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-131 https://tools.oasis-open.org/issues/browse/CAMP-131 MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-127 https://tools.oasis-open.org/issues/browse/CAMP-127 MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-125 https://tools.oasis-open.org/issues/browse/CAMP-125 MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-122 https://tools.oasis-open.org/issues/browse/CAMP-122 MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-120 https://tools.oasis-open.org/issues/browse/CAMP-120 MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd. ... no discuss, no object. Pass UNAN. issue: CAMP-119 https://tools.oasis-open.org/issues/browse/CAMP-119 MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd. ... no discuss, no object. Pass UNAN. chair: we have handled a 3rd of our PR issues so far! Pro-temp chair for the wednesday session : Chair (martin) motions that Adrian chairs the remainder of the F2F , Gil 2nd. ... no discuss, no object. Pass UNAN. chair: meeting recessed until Wed 3:30pm UK time [Meeting restarts] [Adrian charing] [Anish Scribing] Issue: CAMP-145 (again) https://tools.oasis-open.org/issues/browse/CAMP-145 Motion: m:Gil s:Alex resolve issue 145 with the proposal in Jira (v3) tom: what happened to section 3? gil: put it back in and removed references to resources that no longer exist Gil talks about what is now in section 3 Need a new issue to figure out we still need section 3 tom: does the plan resource exist before the PDP is posted to the assembly? gil: if the provider supports plans then posting a PDP to assemblies results in an assembly and a plan MartinC not that im listening but we did have an issue to loook at merging 2 and 3 and now with the re-write the two could condense nicely into a single section Adrian Otto (Rackspace): martin, do you know if that is a PR issue, or a spec issue? MartinC: pr issue - one of patrick's - the one where he was confused between the uml class diagram and instance diagrams adrian: safer to open a new issue, if the issue that martin points out is already there we can close it as dup no more discussion on the motion motion approved w/o RESOLUTION: CAMP 145 is resolved with proposal in JIRA <applause> Topic: issues 5, 22, 23, 29, 64, 77, 82, 141, & 145 adrian reviews issue 5 proposals for all the issues are CNA with a reference to 145 adrian reviews issue 22 adrian reviews issue 23 adrian reviews issue 29 adrian reviews issue 64 adrian reviews issue 77 adrian reviews issue 82 adrian reviews issue 141 adrian reviews issue 145 adrian reviews issue 145 Motion: m:Gil s:Ashok Close issues CAMP-5, CAMP-22, CAMP-23, CAMP-29, CAMP-64, CAMP-77, CAMP-82, and CAMP-141 with no action as they are resolved by resolution of issue CAMP-145 no discussion motion approved w/o RESOLUTION: Issues 5, 22, 23, 29, 64, 77, 82, and 141 are closed with no action (resolved by issue CAMP-145) Topic: issues 85, 86, 87, 89, 90, 92, 93, 94, 96, 128, 123, 132, 141 Adrian discusses each issue and its proposal 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." mark: need to worry about requirements of taking our spec to ISO mark: adding it to our appendix would also be an option mark: if we could enlist folks like Tim Bray/MarkN to move this to IETF Gil Pilz (Oracle): Would adding it to our appendix make us responsible for it? Gil Pilz (Oracle): If not, how does that help anyone? ACTION: Mark to engage with Tim Bray/MarkN to see if YAML 1.1 can be moved to IETF tom: note that the copyright stmt allows copying ... wrt ISO there are ways around this, such as reference explanatory note AI: Mark to contact @tbray, @mnot to see if they can champion YAML in IETF anish: taking the spec thru an org like IETF would result in the spec itself changing ashok: do we really feel that strongly on YAML? adrian: the move to use yaml is to help devs and human beings ... for example json doesn't allow comments ... we are trying to track implementers preferences 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." ... if OASIS comes back saying no way we can host/copy it, we'll have to reconsider Mark: example of JSON proposal by tim bray that does not want to change anything. Same will be true for YAML anish: keep this issue out of the block motion, as we don't know what oasis' answer will be Ashok Malhotra (Oracle): +1 to Anish anish: add security consideration section to the spec adrian walks thru proposal for issue 89 changed 'roles' to 'actors' changed section 1.6 Terminology included definition for CAMP provider and Consumer Adrian walks thru proposal for issue 90 90 is addressed by issue 99 Adrian walks thru proposal for issue 92 editorial issue Adrian walks thru proposal for issue 93 Adrian walks thru proposal for issue 94 Adrian walks thru proposal for issue 96 https://tools.oasis-open.org/issues/browse/CAMP-96 motion m:Gil s:Anish Move to close CAMP- 96 with no action as it is already resolved by issue CAMP-145 resolution no discussion motion approved w/o RESOLUTION: Issue 96 closed with no action as it is already resolved by resolution of issue 145 Adrian discusses issue 128 adrian: this is not ready for resolution. we don't yet address the media types issue Adrian walks thru proposal for issue 123 Adrian walks thru proposal for issue 132 https://tools.oasis-open.org/issues/browse/CAMP-132 Motion: m:Gil s:Anish close issue 132 to close it with no action no discussion motion approved w/o RESOLUTION: issue 132 is CNA Adrian Otto (Rackspace): Completed review of: CAMP-85, CAMP-87, CAMP-89, CAMP-90, CAMP-92, CAMP-93, CAMP-94, CAMP-123 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 no discussion motion approved w/o RESOLUTION: CAMP-85, CAMP-87, CAMP-89, CAMP-90, CAMP-92, CAMP-93, CAMP-94, CAMP-123 resolved with proposals in Jira Topic: Schedule https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50034/CAMP%20sched%202013-07-19.pdf anish: we are already late by 2 weeks ... we have to let Jacques take the changes and accommodate the test suite ... we also have to deal with Jacques challenges ... no major issues left ... perhaps move it by 3 weeks so 2nd PR end of 1st week of November; start of CS ballot end of 1st week of december no one objects Topic: raising the bar on new issues Ashok Malhotra (Oracle): I thought it was 2/3 "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. Adrian Otto (Rackspace): 2/3 of voting members present 2/3 of voting members present & voting 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 anish: reminder that PR is an escape hatch no discussion motion approved w/o RESOLUTION: new standing rule to require 2/3 majority of voting members present and voting to open new issues against CAMP 1.1 [Chair notes that we made the following motion on 2nd October 2013: MOTION: GIl - after 16th October, we raise the bar that requires 2/3 of those on a call to vote in favor to open a new issue against V1.1 2nd: adrian No obj. Motion carries. 16 october is bar raising date ] Topic: new issue 146 https://tools.oasis-open.org/issues/browse/CAMP-146 deferred till next call Topic: types, superclass, subclass, inheritance and substitutability related to issue CAMP-44 https://tools.oasis-open.org/issues/browse/CAMP-44 Gil: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50959/camp-spec-v1.1-issue-44.doc Alex argues for multiple-inheritance issue of diamond inheritance Gil argues for single-inheritance 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 Derek: agree with Alex. There are ways to address the ambiguity problems Tom: there has to be rules about common attributes. We could say that we disallow it if there are common attribute names with different types ... This is complicating this. We have to justify adding complicated rules 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. Adrian: do you have any in mind? Ashok: no. but can research this Gil: we are making comparison to programming languages. But we don't have a compiler. All we got is a type definition. ... it is a definition of particular resource type ... the mechanisms to get multiple inheritance to work escapes me ... no existing implementations to worry about ... understand the usecases and desire. ... we should postpone this till the next version Alex: it is actually pretty easy to implement ... i would be OK with leaving it as is ... but if we were going to have inheritance then it would drive me bonkers if multiple-inheritance did not exist Derek: was thinking of proposing a syntax for this. An array might just do it. Gil: our type definitions do not say anything about operation. Alex: would be fine with it. Adrian: would be an interesting extension ashok: what happens if two attributes have the same name and they don't match alex: in some cases it would be an error if it is not possible 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/ Lots of freeform discussion between Alex and Gil 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 Alex Heneveld: @Tom - looking at that section. it seems quite simple. Gil: it is going to result in something equally complex 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. ... would prefer to leave it out. But if we can't then just bite the bullet and do it Alex: we got a lot of attributes and the only way we know it's there is thru the type system ... if we can find a simple solution quickly we should put it in. But if we can't we can just leave it out Adrian: if we have an array for inheritance then implementations can decide whether to use inheritance 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 <Open ended discussion not scribed> AOB: Topic: straggler roll Thanks to Fujitsu for hosting the f2f. Great network Adrian: martin not available next week. Unless we hear from Martin I'll be your pro-tem chair next week Meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]