On Thu, 13 May 2004 15:32:07 -0400 Will Berry <[EMAIL PROTECTED]> wrote:
> Feargal Reilly wrote: > > >... it's then up to the end-user as to how they use it ... > > > > Since the exact format and treatment of a 'gecos' field would be defined > by the application, I think it's best to use the client_idnr field in > the user table as a pointer to any application-specific data in another > table or database. We use the client_idnr to tie a DBMail user to a > virtual host account on our system, for example. (Although I think for > 2.0 it would be a good idea to rename this field to 'userdata' or > something else more generic; the time to do that is in a new major > release number.) > > But if there's an RFC or something that clearly defines how such data is > to be used, then even if DBMail doesn't actually use it there should be > no problem defining it in the tables. I had a look last night and could not find a formal definition of it. Common usage however indicated that most flavours of unix treat it the same. It is a comma seperated list which takes the following order: Full name, Office Location/Room Number, Office/Work Phone Number, Home Phone Number, Other/Miscellaneous. Many applications look up the first field to insert a user's name. Some, such as finger, chfn, and adduser uses the other information too. I checked this on FreeBSD, Debian, Red Hat, and Solaris. Apparently Solaris they only used two labels - Full Name and other. I agree on you with using the client_idnr for tying to other databases; the GECOS field is not intended for that. I suggest it as it satisfies the needs of many people who do not need to develop a full blown user management database. I would suggest that if renaming the client_idnr field, it should be called 'group' or 'group_idnr'. -fr. -- Feargal Reilly, Codeshifter, Chrysalink Systems.
pgpY1QfHqrizQ.pgp
Description: PGP signature
