[vdsm] [RFC] Implied UUIDs in API

[Alon Bar-Lev]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Saggi Mizrahi" <smizrahi at redhat.com>, "arch" <arch at ovirt.org>, "VDSM Project Development"
> <vdsm-devel at lists.fedorahosted.org>
> Sent: Friday, August 31, 2012 12:23:38 PM
> Subject: Re: [vdsm] [RFC] Implied UUIDs in API
> 
> On 08/31/2012 12:33 AM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> >> To: "arch" <arch at ovirt.org>, "VDSM Project Development"
> >> <vdsm-devel at lists.fedorahosted.org>
> >> Sent: Friday, August 31, 2012 12:19:46 AM
> >> Subject: [vdsm] [RFC] Implied UUIDs in API
> >>
> >> Hi, in the API a lot of IDs get passed around are UUIDs.
> >> The point is that as long as you are not the entity generating the
> >> UUIDs the fact that these are UUIDs have no real significance to
> >> you.
> >> I suggest removing the validation of UUIDs from the receiving end.
> >> There is no real reason to make sure these are real UUIDs.
> >> It's another restriction we can remove from the interface
> >> simplifying
> >> the code and the interface.
> >>
> >> Just to be clear I'm not saying that we should stop using UUIDs.
> >> For example, vdsm will keep generating task IDs as UUIDs. But the
> >> documentation will state that it could be *any* string value.
> >> If for some reason we choose to change the format of task IDs.
> >> There
> >> will be no need to change the interface.
> >>
> >> The same goes for VM IDs. Currently the engine uses UUIDs but
> >> there
> >> is no reason for VDSM to enforce this and limit the engine from
> >> ever
> >> changing it in the future and using other string values.
> >
> > I agree that UUID is just a method of generating unique strings,
> > there is no reason to validate the value nor the format.
> 
> I'm with daniel on this one - knowing a field is a uuid makes it
> easier
> to deal with in the db and code around it compared to a string
> (stored
> binary instead of string representation, etc.)
> 

Why to store binary?

Alon.