Actually, we need both. It's perfectly valid to index and address users by guid in the known internal scope - but conversely, invalid to refer by guid in a cross-scope case. Also, the guid contains no 'resource location' data, which urls are meant to provide.
So, A local user would have a guid ID at any rate. The hashing algorithm seems fair enough to me, IE, hash the url with a scope-wide secret salt, and use that only for internal indexing, ie, fetch the user profile from the url, but assign it the salted hash guid as ID internally. Keep in in-memory on-demand and never write it to db. Of course, this means you'll have to make sure all references to it is by url, not id. Incidentally, I'm thinking we could do the same for assets - let regions substitute urls embedded in assets with hashed salted guids, allowing us to reference web resources (jpegs/pngs) in other assets - and if needed for a particular protocol, autoconvert them to, say, j2000. The general idea is to treat what is now the grid scope as the region scope, essentially converting the region to a cache/conversion mechanism for the wider web. And yes, I'm not saying there will not be problems. There will be tons of them. But again, think of the possibilities. One could start by solving one case, then the next, and so on. :-D Best regards, Stefan Andersson Tribal Media AB > Date: Mon, 30 Mar 2009 08:08:30 -0400 > From: [email protected] > To: [email protected] > Subject: Re: [Opensim-dev] RFC: Ways of creating profiles for creators who > will never log in > > Melanie wrote: > > I am absolutely sure that I would not went HG to ever, EVER, insert > > user records or profile records into my database. I strongly favor > > the "URL" approach, which is neutral as far as my database goes. > > Ok, so then hash those urls for UUIDs to present to the viewer? We > still need a UUID in the object definitions for the viewer so that > people can see the creator. > > -Sean > > -- > Sean Dague / Neas Bade > [email protected] > http://dague.net > >
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
