I would like to see you guys put a heavier design emphasis on using the UID as the only way to uniquely identify any particular user, instead of 'usually' using UID, but 'sometimes' using the U_Username field. I found this oddity when encountering the Address Book feature, and I am recoding it here to use the UID, as the integration modifications I am doing are an integration of our existing account database and the UBB.threads database, in which more than one user can have the same 'U_Username' property (there are other distinguishing fields that I have added), though the UID is always unique. This should make it easier for people doing modifications like myself, and would make the identification of a user standard across all of the code, at the expense of additional queries to translate user id -> display name, though it doesn't look like it would be a significant number of additional queries.

Thank you,

Mike

The new product will always use a numeric user identifier in the database.

Please note that for the current time, having multiple uses with the same display name, or single users with a display name that duplicates a login name belonging to someone else is a BAD idea.

At one time .threads was keyed entirely on the U_Username field, which meant that a user could never change displayed name, would have to reregister to use a new name, would have multiple acocunts with the same email..... etc.

In version 6.2 we made the switch to using userid, though there were some legacy pieces that still used U_Username. THe new product will not have legacy code to deal with, it will all be keyed on a user id of some sort, but it will be consistent throughout all of it's functions.