OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [camp] CAMP PDP discussion notes

Thanks Ashok.  Responses inline.

On 23/05/2013 22:59, Ashok Malhotra wrote:
Hi Alex:
A couple of comments inline ...
All the best, Ashok
On 5/23/2013 5:03 PM, Alex Heneveld wrote:
- Alex to open an issue allowing AT's explicitly to refer to PCT's and A's to PC's, so you don't have to always go through an AC(T) (example a site which offers Wordpress blogs as PCT's -- ACT's would just be posts and data, it's the PCT's which are interesting)
To keep the model simple, perhaps all we need is to allow void components
with requirements
That's possible but smells like a hack which we can easily repair.  To me that makes the model simpler -- more consistent and easier to work with.

Could you give an example where typed components are useful?   I think this would help the discussion.
Sure.  Say I'm deploying two web apps A and B where A needs to access B and I want the connection to be secured with a certificate.  In my thinking, with component and requirement types (and assuming the types used below are defined elsewhere) this could all be expressed as:

        id: A
        type: WAR
        content: { href: a.war }
        requirements: [ { type: JavaSystemProperty, key: a.required.service.url, value: "${B.url}" } ]
        id: B
        type: WAR
        content: { href: b.war }
        type: Certificate
        content: { href: b.cert }
         - { type: PresentedBy: fulfillment: B }
         - { type: TrustedBy, fulfillment: A }

This not bad.  (Not sure about the "${B.url}" syntax of course -- that's a discussion for another day!)

We could also support a "short-form" syntax where
- if "components" is a map rather than a list, the keys therein are interpreted as ids
- if "requirements" is a map, the keys therein are interpreted as types
- if "content" is a primitive, it is taken as an href
That's a little bit tedious to spell out in words but simple to implement and it makes a big difference to readability.  The above then becomes:

        type: WAR
        content: a.war
            a.required.service.url: "${B.url}"
        type: WAR
        content: b.war
        type: Certificate
        content: b.cert
          PresentedBy: B
          TrustedBy: A

I can see people having fun writing this!

- people seem generally happy with DP as a bag of components each with requirements

So, stepping back for a minute.  My thinking is that introducing requirement types allows people to innovate in the types in more interesting and powerful ways without the DP structure getting in the way.  Without that, or something similar, I found myself fighting the DP (that's why I brought them in ... I'm always loathe to introduce a new concept!).

- nobody seems opposed to yaml anymore and some people strongly in favour
My concern is not with YAML but with allowing both JSON and YAML.
Early on we decided that we would not support both XML and JSON due to the added complexity
and picked JSON.  Let's use the same argument here and pick either YAML or JSON
Just YAML is fine by me.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]