[Opensim-dev] Proposal to eliminate the name, description and invType fields from the assets db

[Melanie]

+1 for the below, which seems to address all concerns.

Melanie


Teravus Ovares wrote:
> +1 on Replacing libsecondlife.LLUUID with an object that we control,
> however, I'm still thinking that a hash, even a sha1 hash, might not be the
> best tool to accomplish the goal universally.     It really wouldn't be
> 'that' hard to add a lookup table for RandomUUID----> hash---> Data.     The
> query is simple too.
> 
> Best Regards
> 
> Teravus
> 
> 
> On 6/24/08, Stefan Andersson <stefan at tribalmedia.se> wrote:
>> Sean,
>>
>> 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.
>>
>> Best regards,
>> Stefan Andersson
>> Tribal Media AB
>>
>> Join the 3d web revolution : http://tribalnet.se/
>>
>>
>>
>> ------------------------------
>>> Date: Mon, 23 Jun 2008 18:22:46 -0400
>>> From: sean at dague.net
>>> To: opensim-dev at lists.berlios.de
>>> Subject: Re: [Opensim-dev] Proposal to eliminate the name, description
>> and invType fields from the assets db
>>> On Mon, Jun 23, 2008 at 11:13:09PM +0100, Justin Clark-Casey wrote:
>>> <snip>
>>>> If asset uuids are hashes, then they can disappear from the user and
>>>> program's view. Outside of OpenSim, there is no need to manipulate
>>>> uuids in this scenario - collections of objects or scenes can be
>>>> structured in any way that the external program pleases. Instead of
>>>> getting asset uuids on import, the importing process calculates the
>>>> necessary uuids from data, and can ask the asset service whether these
>>>> already exist without needing to actually obtain the blobs.
>>>>
>>>> I think that it's possible to experiment with the hashing idea without
>>>> requiring the whole system to change. Indeed, because of the very
>>>> import scenario outlined above, I may well try using it for importing
>>>> object archives. This shouldn't impact the rest of the system since, of
>>>> course, the chances of collision are small.
>>> Before we do this, we should make sure to actually do the version 5 uuid
>>> implementation, which isn't just sha1, as it does some reserved bytes to
>>> make sure that you can tell from the UUID what version generated it.
>>>
>>> My suggestion, which came out on IRC, is that we create a singleton UUID
>>> generator class that can be configed on construction as to which type to
>>> generate. Then we create version 4 (random, what we have today) and
>>> version 5 (sha1 based on content) implementations (anyone that wants to
>>> implement versions 1 - 3 is welcomed to).
>>>
>>> UUID assignment would come in the form: UUID.Create(assetdata).
>>>
>>> We'll always need UUID type 4 support for prims and other mutable
>>> structures, as type 5 doesn't really make any sense. But for assetid
>>> assignment we can do this in a user configurable manner. Also, because
>>> the uuids are namespaced correctly, we can easily distinguish which were
>>> created in which model.
>>>
>>> Honestly, this is all probably a bit down the road. But looking at the
>>> UUID RFC is a good place to check out some of the peer reviewed models
>>> for generating UUIDs.
>>>
>>> -Sean
>>>
>>> --
>>> __________________________________________________________________
>>>
>>> Sean Dague Mid-Hudson Valley
>>> sean at dague dot net Linux Users Group
>>> http://dague.net http://mhvlug.org
>>>
>>> There is no silver bullet. Plus, werewolves make better neighbors
>>> than zombies, and they tend to keep the vampire population down.
>>> __________________________________________________________________
>>
>> _______________________________________________
>> 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