On Thu, Apr 16, 2009 at 11:23:51PM +0900, Ryota Ozaki wrote: > I should say here I don't intend to replace using numeric uid/gid > with using alphabetical names. This patch intends just to bring > ease of use and identifying what is specified for users (may not > for end-users though). And I don't still have the answer for > the question 'numbers vs. names, which is better?'. The main problem remains you can't use one or the other without loosing the round trip capability, i.e. what you reserialize after parsing won't carry the same set of informations. And considering we don't know if one is better than the other the status-quo should remain to not break existing uses. If someone start to use names because in his environment it's more resilient than ids, then if the serialization looses or breaks the name, precisely because we did an ID lookup on a different environment, it can be considered a bug. That could be trivially triggered by migrating the domain to a different node where /etc/passwd or /etc/groups is not set up in the same way, though the ID used to label the file owner on the shared storage will be the same. If you stick to ID and not suggest a name lookup might be done you somehow close the gap, because the API defines that you need to keep ID as the identifier available on the cluster. With shared storage like NFS I think ID win over name, because that's how the mapping is maintained, and that's what will be important when you consider the portabilitu of the domain/storage rlated informations. So the main question about this patch (which looks fine from purely a code perspective) is mostly, is this a good idea for the user in the end, and I'm afraid it might be misleading, which kind of offset the convenience value in my opinion. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list