No subject


Sat Apr 19 02:14:48 UTC 2014


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=20
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=20
are any major pragmatic obstacles.

Thanks!


Stefan Andersson wrote:
> Justin,
> =20
> whilst you're at it, could you have a look at the feasabilty of just=20
> adding the url to the user profile on the user service on the=20
> originating grid?
> =20
> We should try to move from guid/local to url/global in everything we
do,=20
> even if in babysteps.
> =20
> If we could let the user server serve a controlled subset of the user=20
> profile to the world, that could be used for preserving a link to the=20
> original creator.
>=20
> So, instead of having creator=3D<someGuid> and then have to re-create
that=20
> profile locally, we could have=20
> creator=3Dhttp://users.osgrid.org/users/justincc/
>=20
> Best regards,
> Stefan Andersson
> Tribal Media AB
>=20
>=20
>=20
> =20
>  > 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=20
> 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=20
> not to allow this and that will be the default, I
>  > expect).
>  >
>  > However, unless an item creator has an account on the OpenSim to=20
> 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=20
> automatically allowing login.
>  >
>  >
>  > (1) Create a normal user account but set the password to something=20
> 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=20
> only, which can be used as a flag to disallow logins
>  >
>  > CONS
>  > * Creates user accounts where many details will be irrelevant
unless=20
> item creators then get accounts on the instance.
>  > * Complicates administration tasks (e.g. create user).
>  > ~~~~~
>  >
>  > (3) Separate the current 'users' table into 'userprofiles' and=20
> 'users' tables.
>  >
>  > 'userprofiles' will largely contain all the metadata about a user=20
> 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=20
> (passwordHash, passwordSalt, homeRegion,
>  > homeLocationX, etc.)
>  >
>  > PROS
>  > * Makes it possible to create user profiles without creating user=20
> accounts.
>  > * Makes it possible to have somewhat separate profile and=20
> 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=20
> '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=20
> databases directly
>  > * Complicates administration tasks (e.g. create user).
>  > ~~~~
>  >
>  > I suspect that archiving isn't the only potential use for this=20
> 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=20
> 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
>=20
>=20
>
------------------------------------------------------------------------
>=20
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev


--=20
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

No virus found in this incoming message.
Checked by AVG - www.avg.com=20
Version: 8.0.238 / Virus Database: 270.11.29/2023 - Release Date:
03/26/09 20:05:00



More information about the Opensim-dev mailing list