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

Stefan Andersson stefan at tribalmedia.se
Tue Jun 24 15:03:14 UTC 2008


+1 for soft-wiring assetId to binary data over a hash indirection, thus enabling intra-trust-boundary de-duping.
 
(what he said)
 
Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ 



> Date: Tue, 24 Jun 2008 15:57:33 +0100> From: melanie at t-data.com> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] Proposal to eliminate the name, description and invType fields from the assets db> > +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> _______________________________________________> 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/8002dff1/attachment-0001.html>


More information about the Opensim-dev mailing list