The telecon has decided to move the UID/GID bits from User to the POSIX version of Application (whatever that's called; I'm behind tracking the exact name of things right now). But a question has come up about the meaning of the content of these elements. It is obvious that they have to be able to accept usernames in their xsd:string content (and I'm aware of systems with spaces in usernames, even if this is not something I'd ever do myself) since they're how POSIX user identities are exposed to users normal. However, with names like they have, should they also accept numeric UIDs? I don't have a use case for this (it's a detail I'd want to always hide) and I'm not aware of anyone ever having a wholly numeric username. As I see it, we have three options: * Current name, user-name semantics * Current name, user-name-and-uid semantics * Change name (to UserName?), user-name semantics Which do people prefer? (GID handling should mirror UID handling) Donal.
If we can find a POSIX statement of allowed chars, to support automatic "type" detection by lexical analysis, I think we should do "User" (no "name" or "id") and the polymorphic semantics. However, "sudo" requires a prepended "#" character to indicate a numeric ID in the generic username field of its command-line option syntax, so I am guessing POSIX may not have this guarantee. Otherwise, I think we should use "UserName" and the name-only semantics. I guess numeric ID is esoteric enough to handle through extensions if some subculture actually needs it? Or, would it make sense to just treat the numeric IDs as optional attributes on the elements? I guess we really want a mutually-exclusive specification of name/ID or else we need some sort of statement about consistency of these values? karl On Apr 13, Donal K. Fellows loaded a tape reading:
The telecon has decided to move the UID/GID bits from User to the POSIX version of Application (whatever that's called; I'm behind tracking the exact name of things right now). But a question has come up about the meaning of the content of these elements.
It is obvious that they have to be able to accept usernames in their xsd:string content (and I'm aware of systems with spaces in usernames, even if this is not something I'd ever do myself) since they're how POSIX user identities are exposed to users normal. However, with names like they have, should they also accept numeric UIDs? I don't have a use case for this (it's a detail I'd want to always hide) and I'm not aware of anyone ever having a wholly numeric username.
As I see it, we have three options: * Current name, user-name semantics * Current name, user-name-and-uid semantics * Change name (to UserName?), user-name semantics
Which do people prefer? (GID handling should mirror UID handling)
Donal.
-- Karl Czajkowski karlcz@univa.com
I think the username itself is good enough. It's actually common to see the same username with different uids on different hosts, so I actually find uids not very useful. In some cases in LSF we've even complicated our lives by using uid and username. -- Chris On 13/4/05 07:34, "Karl Czajkowski" <karlcz@univa.com> wrote:
If we can find a POSIX statement of allowed chars, to support automatic "type" detection by lexical analysis, I think we should do "User" (no "name" or "id") and the polymorphic semantics. However, "sudo" requires a prepended "#" character to indicate a numeric ID in the generic username field of its command-line option syntax, so I am guessing POSIX may not have this guarantee.
Otherwise, I think we should use "UserName" and the name-only semantics. I guess numeric ID is esoteric enough to handle through extensions if some subculture actually needs it?
Or, would it make sense to just treat the numeric IDs as optional attributes on the elements? I guess we really want a mutually-exclusive specification of name/ID or else we need some sort of statement about consistency of these values?
karl
On Apr 13, Donal K. Fellows loaded a tape reading:
The telecon has decided to move the UID/GID bits from User to the POSIX version of Application (whatever that's called; I'm behind tracking the exact name of things right now). But a question has come up about the meaning of the content of these elements.
It is obvious that they have to be able to accept usernames in their xsd:string content (and I'm aware of systems with spaces in usernames, even if this is not something I'd ever do myself) since they're how POSIX user identities are exposed to users normal. However, with names like they have, should they also accept numeric UIDs? I don't have a use case for this (it's a detail I'd want to always hide) and I'm not aware of anyone ever having a wholly numeric username.
As I see it, we have three options: * Current name, user-name semantics * Current name, user-name-and-uid semantics * Change name (to UserName?), user-name semantics
Which do people prefer? (GID handling should mirror UID handling)
Donal.
Christopher Smith wrote:
I think the username itself is good enough. It's actually common to see the same username with different uids on different hosts, so I actually find uids not very useful. In some cases in LSF we've even complicated our lives by using uid and username.
On 13/4/05 07:34, "Karl Czajkowski" <karlcz@univa.com> wrote:
Otherwise, I think we should use "UserName" and the name-only semantics. I guess numeric ID is esoteric enough to handle through extensions if some subculture actually needs it?
I'm going to take these as meaning that we should not mandate uids/gids at all (just user names/group names) and that anyone who wants anything else is a) going to have to do an extension and b) probably doing the wrong thing anyway. That suits what I feel very nicely! :^) Thanks for the quick turnaround. Donal.
participants (3)
-
Christopher Smith -
Donal K. Fellows -
Karl Czajkowski