Re: [camp] Cloud Foundry Core

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

On 11/14/2012 11:09 AM, Alex Heneveld wrote:
> Have we discussed a domain-ownership convention for namespacing? ie only
> Acme Corp can use a com.acme.XXX namespace ?

We discussed it briefly at the f2f in the context of the extensibility 
issue (and how to enable distributed development of extensions), but no 
decision was made regd this.

> That gets around the need for a registry.
>
> Also the maven monotonically increasing version convention (for
> non-snapshot components) ?

IIRC, we did not go into any detailed versioning discussion (yet).

-Anish
--

> --A
>
>
> On 14/11/2012 18:47, Tobias Kunze wrote:
> > Just to clarify: yes, we'll need a registry if portability is to be
> > ensured. Until then, though, this mechanism is sufficient to ensure
> > that new services may be discovered.
> >
> > Of course, if Capabilities and Requirements are used, the symbols used
> > there need to be defined/registered, but that is outside of  the spec
> > as I understand it at this point.
> >
> > -Tobias
> >
> >
> > > > Without some agreement the "name", the attribute space (e.g.
> > > > "tomcatVersion", "javaVersion", etc.), and the value-space of those
> > > > attributes - you can't tell if this template describes "the same
> > > > service" as the ones described by Cloud Foundry (or some other
> > > > registry).
> > > Yes, but that's OK I'd think.
> > >
> > > -Tobias
> > >
> > >
> > > On Nov 14, 2012, at 8:59, GILBERT PILZ <gilbert.pilz@oracle.com> wrote:
> > >
> > > > But what you get when you dereference the links in
> > > > Platform.platformComponentTemplates[] is something like  the following:
> > > >
> > > > {
> > > > "uri" :
> > > > "http://slc03lgx.us.oracle.com/campSrv/PlatformComponentTemplate/2";,
> > > > "name" : "Apache Tomcat 7.0.29",
> > > > "description" : "Bitnami TomcatStack 7.0.29-0",
> > > > "created" : "2012-09-10T16:34:00-0800",
> > > > "resourceState" : {
> > > >    "state" : "READY"
> > > > },
> > > > "tomcatVersion" : "7.0.29",
> > > > "javaVersion" : "1.6.0_33",
> > > > "servletVersion" : "3.0",
> > > > "jspVersion" : "2.2"
> > > > }
> > > >
> > > > Without some agreement the "name", the attribute space (e.g.
> > > > "tomcatVersion", "javaVersion", etc.), and the value-space of those
> > > > attributes - you can't tell if this template describes "the same
> > > > service" as the ones described by Cloud Foundry (or some other
> > > > registry).
> > > >
> > > > ~ gp
> > > >
> > > > On 11/14/2012 8:33 AM, Tobias Kunze wrote:
> > > > > I think we have a mechanism, although not one dedicated to
> > > > > discovering new services: Platform.platform_component_templates[]. No?
> > > > >
> > > > > -Tobias
> > > > >
> > > > >
> > > > > On Nov 14, 2012, at 8:02, Ashok
> > > > > Malhotra<ashok.malhotra@oracle.com>  wrote:
> > > > >
> > > > > > Do we have an issue that covers service discovery or should we
> > > > > > open one?
> > > > > > All the best, Ashok
> > > > > >
> > > > > > On 11/14/2012 7:47 AM, Behrens, Michael V CTR (US) wrote:
> > > > > > > Good info...Having a query REST API to get a list of services
> > > > > > > from a provider sounds like a basic/important interface.  If new
> > > > > > > services are installed, they should be able to make themselves
> > > > > > > visible, however that might be an internal mechanism (outside the
> > > > > > > spec).
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: camp@lists.oasis-open.org
> > > > > > > [mailto:camp@lists.oasis-open.org] On Behalf Of Adrian Otto
> > > > > > > Sent: Wednesday, November 14, 2012 10:22 AM
> > > > > > > To: camp@lists.oasis-open.org
> > > > > > > Subject: [camp] Cloud Foundry Core
> > > > > > >
> > > > > > > Today there was an announcement in the news you should be aware
> > > > > > > of. The Cloud Foundry guys have made an attempt at
> > > > > > > cross-installation compatibility by defining supported
> > > > > > > application frameworks and services that applications can use.
> > > > > > > There is a test tool. If the list of standard ones is present,
> > > > > > > then you are considered compatible, and an application expecting
> > > > > > > those components is expected to work when moved to that platform.
> > > > > > >
> > > > > > > http://core.cloudfoundry.org/definition
> > > > > > >
> > > > > > >
> > > > > > > It seems simple, but it does validate the idea of keeping some
> > > > > > > registry or list of common common components, and a well defined
> > > > > > > way to check if a given application is expected to work on a
> > > > > > > target platform.
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: camp-unsubscribe@lists.oasis-open.org
> > > > > > For additional commands, e-mail: camp-help@lists.oasis-open.org
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: camp-unsubscribe@lists.oasis-open.org
> > > > > For additional commands, e-mail: camp-help@lists.oasis-open.org
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: camp-unsubscribe@lists.oasis-open.org
> > > > For additional commands, e-mail: camp-help@lists.oasis-open.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: camp-unsubscribe@lists.oasis-open.org
> > > For additional commands, e-mail: camp-help@lists.oasis-open.org
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: camp-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: camp-help@lists.oasis-open.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: camp-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: camp-help@lists.oasis-open.org