Re: Module naming and identification

Just to be clear, there are both "strong names" (or "self- 
authenticating identifiers") that map to an immutable string of bytes  
and "strong names" that map to a dynamic string of bytes (just like a  
filename does on your local filesystem). Self-authenticating  
identifiers to immutable files are based on cryptographic hash  
functions.  Self-authenticating identifiers to mutable files are  
based on public key cryptography.

Microsoft has blazed a trail here, and I am glad they did, because  
now instead of arguing that it is feasible I can just point and say  
"Look: Microsoft already did it.":

http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx

To give credit where due, Freenet, the Self-certifying Filesystem,  
and others previously explored the design of a mutable file which is  
identified by its public key, but Microsoft is the first to 1. apply  
that design to the problem of code importing, and 2. actually  
implement it and deploy it on a massive scale.

By the way, my current primary hacker project, the Tahoe Least- 
Authority Filesystem also features semantics like this.  Mutable  
files are identified by their public key.  If I give you such an  
identifier, then you can later read the contents of the file and be  
sure, due to the digital signature on those contents, that those  
contents were acceptable to the holder of the corresponding private key.

http://allmydata.org

Only the immutable kind suffer from the "over-specification" problem  
that Lex Spoon described -- that specifying that you require a  
specific version of your dependency is too tight, and you really want  
to specify things like "Any version of foomodule greater than or  
equal to 1.0.2 and less than 2.0".  The mutable kind of self- 
authenticating identifier are just as flexible as filenames are.

Regards,

Zooko