[gmpi] Re: Bridging GUIDs and URIs

  • From: "Ron Kuper" <RonKuper@xxxxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Thu, 10 Feb 2005 09:50:27 -0500

>>>
> Using a hash of a URI seems like the worst of both worlds to me... 
Care to explain why? 
<<<

Because this would add a layer of indirection without any benefit.  What
I mean is, we decide that URI will be used to both uniquely identify a
plugin as well as locate it, then our factory code ought to simply take
a URI, not a UUID.

Also, a hash of 2 identical URIs will yield the same UUIDs.  So the
punter who isn't careful in choosing his URI still can create a name
collision.

By the way, I should mention some real-world experience we had in SONAR
dealing with vast numbers of UUIDs.  I believe this problem will
resurface, possible even worse, if we use URIs.

SONAR has a COM object to manage all automation data (envelopes,
notification groups, gangs, etc.)  We created a system where each
parameter type had a UUID, and each "container" (track, bus, etc) also
had its own UUID.  We would keep various maps of all of these parameters
and containers, to do things like "what parameters are exposed by track
X effect Y?"

What we found was a huge performance problem.  Using a UUID as a key in
a map means you need to write a compare function that compares 2 128-bit
quantities.  This dramatically slowed down search times, even in
associative STL containers.

Ultimately we wound having to create an auxiliary map that reassigned
every UUID in the known "runtime universe" to a 32-bit integer.

I'm a bit worried that if we get too deep into URIs, we're going to get
into a situation where other hosts and/or plugins could run into similar
bottlenecks.


-----Original Message-----
From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx] On
Behalf Of Steve Harris
Sent: Thursday, February 10, 2005 9:36 AM
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: Bridging GUIDs and URIs

On Thu, Feb 10, 2005 at 08:56:40AM -0500, Ron Kuper wrote:
> UUIDs are 128 bit quantities.  

Even better.
 
> Using a hash of a URI seems like the worst of both worlds to me... 

Care to explain why?

To clarify, the public face would be the URI, the hash would just be
used
in the COM object.

- Steve

> 
> -----Original Message-----
> From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx] On
> Behalf Of Steve Harris
> Sent: Thursday, February 10, 2005 4:12 AM
> To: GMPI Reqs. List
> Subject: [gmpi] Bridging GUIDs and URIs
> 
> I've used the XPCOM interface inside Mozilla, but that either doesnt
> have,
> or doesn't expose the GUID gubbins to developers, so this may be off
> mark,
> but...
> 
> A well known* technique for processing huge volumes of URIs is to hash
> them
> with a universal hash (such as MD5), this gives you a non-colliding
> identfier of 64-128 bits.
> 
> My understanding is that GUIDs are 64bit integers. So, can we take a
> hash
> of the URI thats used for plugin identification, and use that as the
> GUID
> for the COM object? It requires that developers can set the GUID for
> thier
> COM objects, and I dont know if that can be done, but it seems like a
> way
> to use URIs for identification, and keeping COM compatability where
that
> matters.
> 
> - Steve
> 
> * http://eprints.ecs.soton.ac.uk/8231/ sec 4.4 pg. 7
> 
> ----------------------------------------------------------------------
> Generalized Music Plugin Interface (GMPI) public discussion list
> Participation in this list is contingent upon your abiding by the
> following rules:  Please stay on topic.  You are responsible for your
> own
> words.  Please respect your fellow subscribers.  Please do not
> redistribute anyone else's words without their permission.
> 
> Archive: //www.freelists.org/archives/gmpi
> Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to
unsubscribe
> 
> 
> ----------------------------------------------------------------------
> Generalized Music Plugin Interface (GMPI) public discussion list
> Participation in this list is contingent upon your abiding by the
> following rules:  Please stay on topic.  You are responsible for your
own
> words.  Please respect your fellow subscribers.  Please do not
> redistribute anyone else's words without their permission.
> 
> Archive: //www.freelists.org/archives/gmpi
> Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to
unsubscribe

----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your
own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe


----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: