IWHD API Suggestions

Jeff Darcy jdarcy at redhat.com
Thu Sep 8 12:41:58 UTC 2011


On Wed, 7 Sep 2011 16:50:42 -0600
Pete Zaitcev <zaitcev at redhat.com> wrote:

> > So each resource should contain an ID and a its address as bare 
> > minimum.  These are typically set as attributes on the resource
> > root element.  e.g.  So imagefactory would do away with keys and
> > uuids or whatever its using atm to identify resources and use the
> > ID Attribute instead, and also include a reference to its address
> > in as a href attribute on the root element:
> > 
> > <image id="1234" href="http://localhost:9090/images/1234">
> 
> Oh, bummer. We do not (necesserily) have IDs of this nature. This is
> because iwhd possibly manages objects stored in cloud object stores,
> and we only thought about defining mappings from iwhd object keys
> to back-end IDs, names, keys, or whatever it is the cloud in question
> uses to index its objects.
> 
> I suppose what we could do is to define an attribute "_id" with
> the following properties:
>  - set to random UUID value at object creation if not supplied,
>    or fetched from HTTP header
>  - when collection is fetched, it goes into "id" XML attribute
> 
> What Would Jeff Say, I wonder.

It doesn't seem that controversial to me.  I do believe that iwhd
should be usable as a generic object store, and have generally resisted
changes that are too specific to the Aeolus use case, but this
particular change doesn't seem to contradict that goal.  While
automatically generated IDs might not be all that useful in other
contexts, adding them doesn't force users to learn Aeolus concepts and
doesn't seem all that difficult or invasive.

Besides, I'm not sure I should even get a vote any more.  I'm just here
to ask and (even more rarely) answer questions, but I'm not enough of a
stakeholder any more to have even a minimal role in actually making
decisions.


More information about the iwhd-devel mailing list