----- Original Message ----- > From: "Saggi Mizrahi" <[email protected]> > To: "arch" <[email protected]>, "VDSM Project Development" > <[email protected]> > 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. Thanks, Alon. _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
