That's what I was thinking might be best approach for user uris too - rather than changing the data schema for user uuids, augment user identification with the uri to their home grid.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Melanie Sent: 27 March 2009 15:57 To: [email protected] Subject: Re: [Opensim-dev] RFC: Ways of creating profiles for creators who will never log in An asset URI might just be http://asset_server/assets/asset_uuid So, local lookups can be UUID in the DB table. It's remote references that need to be augmented, since a UUID doesn't contain the information on where to fetch it from. Melanie Chris Hart wrote: > 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. > > 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 > > _______________________________________________ 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
