Re: [occi-wg] Ambiguity regarding Collections
Sorry, forgot to CC the list. ---------- Forwarded message ---------- From: <shlomo.swidler@gmail.com> Date: Wed, Jun 24, 2009 at 11:43 PM Subject: Re: [occi-wg] Ambiguity regarding Collections To: Sam Johnston <samj@samj.net>
Great - we discussed how the specification would be documented on today's call and there was some concern that it wouldn't be long/formal enough if we continue on as I've started but I'd prefer to produce something that is as concise as possible (ideally no more than a few pages).
This is yet another reason why it's important to have multiple, independent implementations: spec ambiguity can be discovered by comparing the differences between implementations. Have you considered having an official "OCCI Compatibility Test", which could be an impartial arbiter of whether or not a given implementation is spec compliant?
- If you retrieve a representation of a single resource you will get just the representation itself (with the metadata out of harm's way in the headers) - If you instead request something that *could* return multiple resources (e.g. a category, search, etc.) then you will receive a feed with zero or more entries.
This seems OK to me, as long as the disposition of each method (whether it only ever returns a single resource, such as GET /compute/uuid1, or whether it can return multiple resources, such as a search) is clearly indicated in the spec. .. Shlomo
Hi, This is yet another reason why it's important to have multiple,
independent implementations: spec ambiguity can be discovered by comparing the differences between implementations.
There's a few different options for this but outside of any reference implementations we develop alongside the spec (e.g. the one I whipped up on Google App Engine earlier) I think it's something we can focus on once we have a draft out the door (which I hope will happen very, very soon).
Have you considered having an official "OCCI Compatibility Test", which could be an impartial arbiter of whether or not a given implementation is spec compliant?
Sure, that's a good idea but who's to say our implementation will be any better than any other? Bakeoffs tend to work well too.
- If you retrieve a representation of a single resource you will get just the representation itself (with the metadata out of harm's way in the headers) - If you instead request something that *could* return multiple resources (e.g. a category, search, etc.) then you will receive a feed with zero or more entries.
This seems OK to me, as long as the disposition of each method (whether it only ever returns a single resource, such as GET /compute/uuid1, or whether it can return multiple resources, such as a search) is clearly indicated in the spec.
Yup, agreed (and at least for now this is certainly the case). I forgot to mention that one of the key reasons for this approach is to lower the barriers to entry (it becomes trivial to "kick the tyres" - even with nothing more than a browser) and to allow for very simple clients like scripts and cron jobs to do routine tasks (e.g. integration and automation). Sam
Have you considered having an official "OCCI Compatibility Test", which could be an impartial arbiter of whether or not a given implementation is spec compliant?
Sure, that's a good idea but who's to say our implementation will be any better than any other? Bakeoffs tend to work well too.
In the absence of an official compatibility test, what must an implementor do in order to be sure his implementation is spec compliant? I'm not familiar with how a bakeoff works - can you please explain? .. Shlomo
On Wed, Jun 24, 2009 at 11:31 PM, <shlomo.swidler@gmail.com> wrote:
Have you considered having an official "OCCI Compatibility Test", which could be an impartial arbiter of whether or not a given implementation is spec compliant?
Sure, that's a good idea but who's to say our implementation will be any better than any other? Bakeoffs tend to work well too.
In the absence of an official compatibility test, what must an implementor do in order to be sure his implementation is spec compliant?
Don't get me wrong - testing is important, just not today while we're trying to get a[n overdue] draft out the door. Correct functioning against a reference implementation would be a good start.
I'm not familiar with how a bakeoff works - can you please explain?
We put implementors in a [virtual] room together and point their work at each other, seeing where the wheels fall off and fixing it (and/or the spec itself). With any luck we'll be able to do some of this before the spec is finalised. Sam
Don't get me wrong - testing is important, just not today while we're trying to get a[n overdue] draft out the door. Correct functioning against a reference implementation would be a good start.
Sam, thanks for clarifying the process. I didn't mean to imply that we need to work on compliance tests now, I'm just wondering if this is a deliverable we will provide at some point, and whether or not it will be available "in time" to help spec implementors. .. Shlomo
On Thu, Jun 25, 2009 at 12:16 AM, <shlomo.swidler@gmail.com> wrote:
Don't get me wrong - testing is important, just not today while we're trying to get a[n overdue] draft out the door. Correct functioning against a reference implementation would be a good start.
Sam, thanks for clarifying the process.
I didn't mean to imply that we need to work on compliance tests now, I'm just wondering if this is a deliverable we will provide at some point, and whether or not it will be available "in time" to help spec implementors.
It would definitely be nice to have, and the reference implementation we have today is for the server side interface (that is, only useful for testing clients). It's not on our official list of deliverables though - I'm fairly confident the interop problems will be with the data interchange format(s), as is the case today (OVF isn't really working as intended just yet). Thanks for the feedback - do you have any thoughts about the interface itself? Sam
participants (2)
-
Sam Johnston -
shlomo.swidler＠gmail.com