<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Sean,<BR>
<BR>
Regardless possibly differing end goals, I'm all +1 on this one. We have been talking about doing something about the LLUUIDs for so long, this is an excellent opportunity and tactic to do so.<BR><BR>Best regards,<BR>Stefan Andersson<BR>Tribal Media AB<BR> <BR>Join the 3d web revolution : <A href="http://tribalnet.se/" target=_blank>http://tribalnet.se/</A><BR> <BR><BR><BR>
<HR id=stopSpelling>
> Date: Mon, 23 Jun 2008 18:22:46 -0400<BR>> From: sean@dague.net<BR>> To: opensim-dev@lists.berlios.de<BR>> Subject: Re: [Opensim-dev] Proposal to eliminate the name, description and invType fields from the assets db<BR>> <BR>> On Mon, Jun 23, 2008 at 11:13:09PM +0100, Justin Clark-Casey wrote:<BR>> <snip><BR>> > If asset uuids are hashes, then they can disappear from the user and <BR>> > program's view. Outside of OpenSim, there is no need to manipulate <BR>> > uuids in this scenario - collections of objects or scenes can be <BR>> > structured in any way that the external program pleases. Instead of <BR>> > getting asset uuids on import, the importing process calculates the <BR>> > necessary uuids from data, and can ask the asset service whether these <BR>> > already exist without needing to actually obtain the blobs.<BR>> > <BR>> > I think that it's possible to experiment with the hashing idea without <BR>> > requiring the whole system to change. Indeed, because of the very <BR>> > import scenario outlined above, I may well try using it for importing <BR>> > object archives. This shouldn't impact the rest of the system since, of <BR>> > course, the chances of collision are small.<BR>> <BR>> Before we do this, we should make sure to actually do the version 5 uuid<BR>> implementation, which isn't just sha1, as it does some reserved bytes to<BR>> make sure that you can tell from the UUID what version generated it.<BR>> <BR>> My suggestion, which came out on IRC, is that we create a singleton UUID<BR>> generator class that can be configed on construction as to which type to<BR>> generate. Then we create version 4 (random, what we have today) and<BR>> version 5 (sha1 based on content) implementations (anyone that wants to<BR>> implement versions 1 - 3 is welcomed to).<BR>> <BR>> UUID assignment would come in the form: UUID.Create(assetdata).<BR>> <BR>> We'll always need UUID type 4 support for prims and other mutable<BR>> structures, as type 5 doesn't really make any sense. But for assetid<BR>> assignment we can do this in a user configurable manner. Also, because<BR>> the uuids are namespaced correctly, we can easily distinguish which were<BR>> created in which model.<BR>> <BR>> Honestly, this is all probably a bit down the road. But looking at the<BR>> UUID RFC is a good place to check out some of the peer reviewed models<BR>> for generating UUIDs.<BR>> <BR>> -Sean<BR>> <BR>> -- <BR>> __________________________________________________________________<BR>> <BR>> Sean Dague Mid-Hudson Valley<BR>> sean at dague dot net Linux Users Group<BR>> http://dague.net http://mhvlug.org<BR>> <BR>> There is no silver bullet. Plus, werewolves make better neighbors<BR>> than zombies, and they tend to keep the vampire population down.<BR>> __________________________________________________________________<BR><BR></body>
</html>