Chris, the problem is that this seems to go back to inserting entries in q database table (so that you can link a certain UUID with a given URI).
I suspect that it's much nicer to be able to pull all the information directly without needing to do that. Chris Hart wrote: > 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 > -- justincc Justin Clark-Casey http://justincc.wordpress.com _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
