Maybe I'm being dumb, but why would you need anything more unique than a unique identifier for a user? I understand if you are talking about having urls to profiles, but you can associate a url with a uuid easily enough, and for local user accounts a url would be easily generated. That would mean a change to the user tables, but not to any other lookups elsewhere, if I understand the relationships right.
>From the MSSQL perspective, as long as no-one gets the bright idea at any point that a uuid isn't the right thing for an asset, we can handle schema changes on MSSQL without too much hassle. MSSQL has a native unique identifier data type, so it was daft not to use it when we use uuids throughout the code - faster indexing and more efficient data storage. Migrating most of a database didn't take long, but the assets took a very long time to migrate since we have a >5Gb database of mostly assets at ReactionGrid now. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Justin Clark-Casey Sent: 27 March 2009 14:59 To: [email protected] Subject: Re: [Opensim-dev] RFC: Ways of creating profiles for creators who will never log in Oh, now that is a most excellent idea, Stefan - one that I think is much better than copying and inserting profiles. And I even think it could be made to work with the current architecture. I think that it will need user ID fields in the database to be made much larger than the current char(36) limits for UUIDS (I'd like to know how this affects MSSQL), so I would probably need to do that unless there are any comments. I shall seriously think about this and take this approach rather than the profile copying I was suggesting unless there are any major pragmatic obstacles. Thanks! Stefan Andersson wrote: > Justin, > > whilst you're at it, could you have a look at the feasabilty of just > adding the url to the user profile on the user service on the > originating grid? > > We should try to move from guid/local to url/global in everything we do, > even if in babysteps. > > If we could let the user server serve a controlled subset of the user > profile to the world, that could be used for preserving a link to the > original creator. > > So, instead of having creator=<someGuid> and then have to re-create that > profile locally, we could have > creator=http://users.osgrid.org/users/justincc/ > > Best regards, > Stefan Andersson > Tribal Media AB > > > > > > Date: Thu, 26 Mar 2009 21:00:16 +0000 > > From: [email protected] > > To: [email protected] > > Subject: [Opensim-dev] RFC: Ways of creating profiles for creators > who will never log in > > > > Hello, > > > > For Inventory Archives I plan to preserve item creator information. > When the archive is loaded I would like to recreate > > these profiles where possible/necessary (grid operators can choose > not to allow this and that will be the default, I > > expect). > > > > However, unless an item creator has an account on the OpenSim to > which the archive is loaded, they shouldn't be able to > > login to that instance. > > > > So far I've thought of 3 ways to create a profile without > automatically allowing login. > > > > > > (1) Create a normal user account but set the password to something > random. > > > > PROS > > * Doesn't require any changes to what we have today > > > > CONS > > * Creates user accounts which are never intended to be used for login > > * No way to distinguish archive created accounts from legitimate accounts > > ~~~~~ > > > > (2) Add a 'ProfileOnly' flag to the Users table > > > > PROS > > * Minimal changes to what we have today > > * Makes it clear that an entries has been created for its profile > only, which can be used as a flag to disallow logins > > > > CONS > > * Creates user accounts where many details will be irrelevant unless > item creators then get accounts on the instance. > > * Complicates administration tasks (e.g. create user). > > ~~~~~ > > > > (3) Separate the current 'users' table into 'userprofiles' and > 'users' tables. > > > > 'userprofiles' will largely contain all the metadata about a user > that you can see in the profile on the Linden Labs > > Second Life client today (name, about, interests, 1st life, etc.). > > > > 'users' will contain the data associated with a particular account > (passwordHash, passwordSalt, homeRegion, > > homeLocationX, etc.) > > > > PROS > > * Makes it possible to create user profiles without creating user > accounts. > > * Makes it possible to have somewhat separate profile and > authentication plugins allow mix & match. However, the reuse > > of avatar name as the login identifier makes things a bit awkward. > > * Simplifies database understandability - the only people in the > 'users' table are those with actual accounts, though on > > the other hand this does create 2 tables instead of 1. > > > > CONS > > * Short term adjustment pain for systems accessing OpenSim's > databases directly > > * Complicates administration tasks (e.g. create user). > > ~~~~ > > > > I suspect that archiving isn't the only potential use for this > functionality. For instance, the Hypergrid may also find > > it useful to preserve user information when a user rezzes an object > on a foreign system. > > > > Of the above approaches, I prefer (3) over (2) since it seems to me > to be the better long term approach even if there is > > some short term pain. I'm don't think that (1) is a good option. > > > > I've reproduced most of text at > http://opensimulator.org/wiki/Creating_profiles_not_used_for_login for > reference. > > > > Comments? > > > > -- > > justincc > > Justin Clark-Casey > > http://justincc.wordpress.com > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev -- justincc Justin Clark-Casey http://justincc.wordpress.com _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.11.29/2023 - Release Date: 03/26/09 20:05:00 _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
