name-based access to resources
Hello, WG. In re-reading the OCCI spec, something became clear to me I frankly hadn't noticed before: All operations require system-generated ids. POST creates an object and returns a url containing its UUID. All other operations require this UUID. UUIDs are important, and there will be systems that should use this for efficiency's sake. However, moderate use would pretty much require users to store a mapping between what they call a resource and its UUID. This mapping would end up as another table or cache that clients would need to maintain. The alternate path is a name-based interface to the system that allows access to resources based on ids the client decides. A good example of this is atmos online, where they have 2 interfaces: /objects and /namespace but offer the same methods on each. For convenience, namespace methods return the UUID in a response header, so one can later switch. Regardless, clients do not need to parse metadata or listings to access their resources as they are available by their natural names. Is this something we can consider supporting in OCCI? Regards, -Adrian jclouds
I believe though discussions, multiple was sidelined to be examined in a later revision. If you could, place it on the issues list. -gary Adrian Cole wrote:
Hello, WG.
In re-reading the OCCI spec, something became clear to me I frankly hadn't noticed before: All operations require system-generated ids. POST creates an object and returns a url containing its UUID. All other operations require this UUID. UUIDs are important, and there will be systems that should use this for efficiency's sake. However, moderate use would pretty much require users to store a mapping between what they call a resource and its UUID. This mapping would end up as another table or cache that clients would need to maintain.
The alternate path is a name-based interface to the system that allows access to resources based on ids the client decides. A good example of this is atmos online, where they have 2 interfaces: /objects and /namespace but offer the same methods on each. For convenience, namespace methods return the UUID in a response header, so one can later switch. Regardless, clients do not need to parse metadata or listings to access their resources as they are available by their natural names.
Is this something we can consider supporting in OCCI?
Regards, -Adrian jclouds _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
I'm comfortable with that. There's nothing about this interface that requires rework of the primary. It is really a 'value-add' that would encourage a few more adopters. Cheers, -Adrian On Tue, Oct 20, 2009 at 5:38 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
I believe though discussions, multiple was sidelined to be examined in a later revision. If you could, place it on the issues list.
-gary
Adrian Cole wrote:
Hello, WG.
In re-reading the OCCI spec, something became clear to me I frankly hadn't noticed before: All operations require system-generated ids. POST creates an object and returns a url containing its UUID. All other operations require this UUID. UUIDs are important, and there will be systems that should use this for efficiency's sake. However, moderate use would pretty much require users to store a mapping between what they call a resource and its UUID. This mapping would end up as another table or cache that clients would need to maintain.
The alternate path is a name-based interface to the system that allows access to resources based on ids the client decides. A good example of this is atmos online, where they have 2 interfaces: /objects and /namespace but offer the same methods on each. For convenience, namespace methods return the UUID in a response header, so one can later switch. Regardless, clients do not need to parse metadata or listings to access their resources as they are available by their natural names.
Is this something we can consider supporting in OCCI?
Regards, -Adrian jclouds _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Well, no work except that we've coded in root-level paths like: /compute in the spec. I'm not sure if we intend that to be taken literally, but if so, it reduces options for exposing multiple interfaces. -Adrian On Tue, Oct 20, 2009 at 5:40 PM, Adrian Cole <adrian@jclouds.org> wrote:
I'm comfortable with that. There's nothing about this interface that requires rework of the primary. It is really a 'value-add' that would encourage a few more adopters.
Cheers, -Adrian
On Tue, Oct 20, 2009 at 5:38 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
I believe though discussions, multiple was sidelined to be examined in a later revision. If you could, place it on the issues list.
-gary
Adrian Cole wrote:
Hello, WG.
In re-reading the OCCI spec, something became clear to me I frankly hadn't noticed before: All operations require system-generated ids. POST creates an object and returns a url containing its UUID. All other operations require this UUID. UUIDs are important, and there will be systems that should use this for efficiency's sake. However, moderate use would pretty much require users to store a mapping between what they call a resource and its UUID. This mapping would end up as another table or cache that clients would need to maintain.
The alternate path is a name-based interface to the system that allows access to resources based on ids the client decides. A good example of this is atmos online, where they have 2 interfaces: /objects and /namespace but offer the same methods on each. For convenience, namespace methods return the UUID in a response header, so one can later switch. Regardless, clients do not need to parse metadata or listings to access their resources as they are available by their natural names.
Is this something we can consider supporting in OCCI?
Regards, -Adrian jclouds _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
That by default is the unidentified and unqualified (by attributes) occi name space. If the representation was in XML, identifying the name space would be less ambiguous. However, other attributes can be added to resolve that issue, but that increases the parsing burden approaching the efficiencies of other formats. There is no free ride here. Either the name space information as meta data is presented and need to be parsed or the meta data is removed and limit name spaces to one type. Reducing functionality is one way of eliminating meta data and improving efficiencies. If you want more functionality, you will have to pay for it. -gary Adrian Cole wrote:
Well, no work except that we've coded in root-level paths like: /compute in the spec.
I'm not sure if we intend that to be taken literally, but if so, it reduces options for exposing multiple interfaces.
-Adrian On Tue, Oct 20, 2009 at 5:40 PM, Adrian Cole <adrian@jclouds.org> wrote:
I'm comfortable with that. There's nothing about this interface that requires rework of the primary. It is really a 'value-add' that would encourage a few more adopters.
Cheers, -Adrian
On Tue, Oct 20, 2009 at 5:38 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
I believe though discussions, multiple was sidelined to be examined in a later revision. If you could, place it on the issues list.
-gary
Adrian Cole wrote:
Hello, WG.
In re-reading the OCCI spec, something became clear to me I frankly hadn't noticed before: All operations require system-generated ids. POST creates an object and returns a url containing its UUID. All other operations require this UUID. UUIDs are important, and there will be systems that should use this for efficiency's sake. However, moderate use would pretty much require users to store a mapping between what they call a resource and its UUID. This mapping would end up as another table or cache that clients would need to maintain.
The alternate path is a name-based interface to the system that allows access to resources based on ids the client decides. A good example of this is atmos online, where they have 2 interfaces: /objects and /namespace but offer the same methods on each. For convenience, namespace methods return the UUID in a response header, so one can later switch. Regardless, clients do not need to parse metadata or listings to access their resources as they are available by their natural names.
Is this something we can consider supporting in OCCI?
Regards, -Adrian jclouds _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi Adrian, It looks like you were referring to the walkthrough which is now well out of date. It will be updated at publication but in the mean time please refer to the spec directly. You'll see that URLs are now in fact opaque and leave structure to the implementors/users (as is the case on the Internet today - we don't tell people they have to put images in /images for example). We still have UUIDs so as resources can be tracked as they move around within/between clouds (in the same way that VMware virtualisation clients complain when you move VMs and ask if you want to keep the old UUID or generate a new one) but they are attributes. This allows people to create sensible URL structures like http://cloud.amazon.com/images/ami-123456 which the clients learn from the protocol itself (in line with RESTful principles). Hope that helps, Sam On Wed, Oct 21, 2009 at 2:26 AM, Adrian Cole <adrian@jclouds.org> wrote:
Hello, WG.
In re-reading the OCCI spec, something became clear to me I frankly hadn't noticed before: All operations require system-generated ids. POST creates an object and returns a url containing its UUID. All other operations require this UUID. UUIDs are important, and there will be systems that should use this for efficiency's sake. However, moderate use would pretty much require users to store a mapping between what they call a resource and its UUID. This mapping would end up as another table or cache that clients would need to maintain.
The alternate path is a name-based interface to the system that allows access to resources based on ids the client decides. A good example of this is atmos online, where they have 2 interfaces: /objects and /namespace but offer the same methods on each. For convenience, namespace methods return the UUID in a response header, so one can later switch. Regardless, clients do not need to parse metadata or listings to access their resources as they are available by their natural names.
Is this something we can consider supporting in OCCI?
Regards, -Adrian jclouds _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (3)
-
Adrian Cole -
Gary Mazz -
Sam Johnston