[Opensim-dev] RFC: Ways of creating profiles for creators who will never log in

Justin Clark-Casey jjustincc at googlemail.com
Fri Mar 27 16:06:06 UTC 2009 

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: opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie
> Sent: 27 March 2009 15:57
> To: opensim-dev at lists.berlios.de
> 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: opensim-dev-bounces at lists.berlios.de
>> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Justin
>> Clark-Casey
>> Sent: 27 March 2009 14:59
>> To: opensim-dev at lists.berlios.de
>> 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: jjustincc at googlemail.com
>>>  > To: opensim-dev at lists.berlios.de
>>>  > 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
>>>  > Opensim-dev at lists.berlios.de
>>>  > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>>
> ------------------------------------------------------------------------
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> 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
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 


-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com

More information about the Opensim-dev mailing list