On 08/31/2012 12:33 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Saggi Mizrahi" <smizr...@redhat.com>
To: "arch" <a...@ovirt.org>, "VDSM Project Development"
<vdsm-devel@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.)
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
