[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [camp] PDP subcommittee and next meeting
Alex et al, I will probably not be able to make this Wednesday's TC call so I was thinking of cancelling and handing over the time slot to a pdp call - this would not be a formal call to maintain voting rights etc. Thoughts? Martin. >-----Original Message----- >From: Alex Heneveld [mailto:alex.heneveld@cloudsoftcorp.com] >Sent: 13 May 2013 18:17 >To: camp@lists.oasis-open.org >Subject: [camp] PDP subcommittee and next meeting > > >Hi folks- > >Thanks to all who joined the call just now. Productive. My notes and thoughts >below. > >I'll send an invite to the list for tomorrow's call at 4pm UK / 8am PDT, using >GTM details (with Switzerland for Anish this time): > > https://www3.gotomeeting.com/join/759306270 > > United States: 1 (646) 982-0002 > United Kingdom: 44 (0) 203 535 0624 > Switzerland: 41 (0) 435 0167 07 > Germany: 49 (0) 811 8899 6976 > Ireland: 353 (0) 14 845 975 > Access Code: 759-306-270 > >Best, >Alex > > >SELECTED NOTES/COMMENTS >(Not intended as a transcript of the call, but my sense and my thoughts. Please >feel free to amend by email.) > >DP component specs -- > typically become components, and often the platform will supply more >components; > but the platform MAY NOT reflect a component in the DP spec with a >component in the platform > (e.g. in a paas which e.g. uses a WAR as an input but doesn't model them as >top-level ACT's) > >There are valid reasons why people would want to represent a Platform >Component in the DP (e.g. providing a concrete topology, asking for a server, >asking for a git repo); but in general leaving it abstract, giving App >Components (artifacts) and requirements, is likely to be more portable / >better. > >Requirements as explicit types (Alex's (1b) ) tentatively seems clearer now, vs >(1a) in Alex's note from Gil. >Requirements expressed in such a way provide abstraction independent of the >component nodes -- more flexible than just components, and more formal and >dependable than mixins (1c). > >Traits as requirements (Alex's (2a) ) as a peer to "relationship" >requirements seems a reasonable >approach but need more time to process. The line between a "provider / >supertype" requirement on a component and the "relationship" is blurry -- e.g. >in case of a git repo, it might be part of a component (e.g. OpenShift) or it >might be a separate component. > >END > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that generates >this mail. Follow this link to all your TCs in OASIS at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]