[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [camp] PDP subcommittee and next meeting
Thank you Alex, @all On the dropbox you can find the Seaclouds-Negotiation-Main-V0.2. with the last changes suggested by Alex. I've re-shaped the Standardization ppt as well. Please feel free to comment. The only slides missing at this moment are the slides from NURO. See you in a couple of hours. Thx and Regards Francesco -----Original Message----- From: camp@lists.oasis-open.org [mailto:camp@lists.oasis-open.org] On Behalf Of Alex Heneveld Sent: martes, 14 de mayo de 2013 12:29 To: Martin Chapman Cc: camp@lists.oasis-open.org Subject: Re: [camp] PDP subcommittee and next meeting 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.ph >> p >> --------------------------------------------------------------------- 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 ------------------------------------------------------------------ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informacion confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente pueden estar protegidos por secreto profesional. Si usted recibe este correo electronico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus. ------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]