PDP subcommittee and next meeting

[Alex Heneveld <alex.heneveld@cloudsoftcorp.com>]

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