Re: [camp] PDP subcommittee and next meeting

[Adrian Otto <adrian.otto@rackspace.com>]

I am also planning to be out due to a special event. I prefer to follow Martin's suggestion to skip one meeting.

--
Adrian

On May 14, 2013, at 5:29 AM, "Alex Heneveld" <alex.heneveld@cloudsoftcorp.com> wrote:

> 
> Only concern is that there are other P1 issues to discuss and at least one proposal.
> If there is a capable pro-tem chair volunteer that might be better?
> 
> --A
> 
> 
> On 13/05/2013 18:55, Martin Chapman wrote:
>> 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
>>> 
> 
> 
> ---------------------------------------------------------------------
> 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