[vdsm] [RFC] Implied UUIDs in API

[Itamar Heim]

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.)