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

[Teravus Ovares]

+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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080624/75973fc7/attachment-0001.html>