[Opensim-dev] On Mantis #1370 (avatar persistence)

[Diva Canto]

Duplication of keys is a non-issue, but addressing is an issue. Given a 
UUID, it's impossible to know to what system it belongs to. This mode of 
identifying things is designed for centralized systems, and as such it 
is fundamentally unscalable. OpenSim will never be able to become the 
Apache server of 3D if it doesn't solve this addressing problem. 
Everything should be qualified with an IP address / domain name + port. 
Something like this:

OSUUID ::= [<protocol>://<domain>[:port][/<type>/]]UUID

If the optional part is missing, the thing is assumed to be in the local 
grid, using the defaults for all of those fields.

Teravus Ovares wrote:
> Just a FYI,
>  
> UUIDS will not be duplicated across grids, we've stated in many forums 
> that the chances of a UUID duplication even across hundreds of grids 
> generating UUIDs at the same time is like winning the lottery 50 times 
> in a row, it just doesn't happen.
>  
> Best Regards
>  
> Teravus
>
>  
> On 6/11/08, *f.d.g.* <opensim-ml at fdg.org <mailto:opensim-ml at fdg.org>> 
> wrote:
>
>     If I'm allowed to throw in my 2 cents...
>
>     Sean Dague wrote:
>     > On Tue, Jun 10, 2008 at 01:39:41AM +0900, liu xiaolu wrote:
>     >> I think it is not necessary (or should not) to check assetID's
>     avaliability
>     >> by using C# code.
>     >> It is a tired, buggy way to go, even you can make "getinventory"
>     >> synchronous.
>     >> Both of the MySQL, MSSQL have the native support of "FOREGIN KEY
>     >> constaints".
>     >> RDBMS should handle such task for us.
>     >
>     > SQLite doesn't handle it natively, and we've not really used foreign
>     > keys anywhere else in the design up till this point.
>
>     If SQLite doesn't handle it (natively), then please don't use it,
>     because: OpenSim right now is (nearly) perfect for SL skin/(basic)
>     clothes designers. They can use the official viewer for previewing,
>     without having to use some 'strange' programs or relying on the beta
>     grid or paying for every upload to SL. The ease of use of OpenSim is
>     given by the simple setup - just hit enter several times. These
>     designers surely don't want to mess around with setting up MySQL or
>     MSSQL or any other database.
>
>
>     The second reason for not relying on the RDBMS "FOREIGN KEY", in my
>     opinion, is the question: Would it work with Capabilities?
>
>
>     In the context of capabilities I hope I'm also allowed to explain my
>     hope on to what OpenSim will develop in the future - and I think the
>     "FOREIGN KEY" perhaps won't work in that situation:
>
>     Right now UUIDs are used as a key to everything. As far as I can see
>     these UUIDs are unique only on one single grid - on another grid the
>     same UUID could point to something completely different. Thus,
>     connecting two grids won't work. As far as I can see the realXtend
>     people do the travelling from one grid to another 'simply' by
>     loging out
>     the current user and loging in a new user on the grid you travel to,
>     thus needing to create accounts on all grids you want to travel to.
>
>     Now, how about 'simply' prepending a fully qualified domain name
>     to the
>     UUIDs? Then the grid you just travelled to could get all the needed
>     data, like avatar appearance, by contacting the 'home' grid of that
>     avatar and caching this needed data as long as the avatar is on that
>     grid - and which grid is the 'home' grid of that avatar it knows from
>     the FQDN prepented to the UUID of that avatar. By the way, I think it
>     then would be needed to prepend a FQDN to every UUID to prevent
>     duplicate UUIDs, like UUIDs for skins, clothes, attachments and so on.
>
>     As far as I can see, this "prepending a FQDN to a UUID" is what
>     capabilities look like, so with the proper use of capabilties
>     throughout
>     the whole system the implementation of 'grid-hopping' would be
>     rather easy.
>
>
>
>     Bye
>     f.d.g.
>     _______________________________________________
>     Opensim-dev mailing list
>     Opensim-dev at lists.berlios.de <mailto: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
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080611/b1d6fe5e/attachment-0001.html>