[e-lang] Module naming and identification

[Zooko O'Whielacronx]

On Tue, Apr 14, 2009 at 5:29 PM, Lex Spoon <lex at lexspoon.org> wrote:
> I agree.  Is there a good name for "reference to a *static*
> bitstream"?

The specific ones we have In Tahoe are called "immutable file caps".
The specific ones they have in Freenet are called "content-hash keys".
 We could call them in general "static file strong names" and "dynamic
file strong names".  (By the way, Microsoft's strong name assemblies
scheme started using static file strong names many years ago -- the
name was the secure hash of the module contents -- and later switched
to dynamic file strong names.)

> In source code, it seems like any kind of strong reference would be
> too specific.  You usually want the local repository to be able to
> choose what the identifier "com/foosrus/foomodule" actually refers to,
> at which points it's not really a strong reference.

I think I now understand what use case you are talking about.  For
this use case strong names don't have to be more specific than any
other method of deciding which modules are in and which are out.

For example, for the Tahoe-LAFS project, I created this directory in
Tahoe to hold Python packages which my code depends on:

http://testgrid.allmydata.org:3567/uri/URI%3ADIR2-RO%3Asnrfwfxatrci35zdgjnzxxx2ke%3Aunarxv347edtku3xzmefy4mcdmfngxzeb72iyqcadbjzjpczjx5a/index.html

(Feel free to snip off the "/index.html" to see the full set of files
in that directory.)

There is (a hash of) a public key in the URL.  Tahoe automatically
creates a digital signature on each file which is uploaded into that
directory.  I can put that URL into my Python project's build
configuration file as a location from which to import modules, and
then the build tool will download packages it needs from that
directory.  The result is that I am the one who controls versions --
by uploading a package to that directory, I cause it to automatically
gain a digital signature which my Python code relies on to decide
which packages to use.

This is, I think, the same use case that you are talking about -- I am
the author of the application and I want to personally control which
modules that application imports.  I could express the same access
control decisions by storing them all in a local directory and
configuring my application to import them from that local directory
instead of from the web.  Serving them through the web makes it easier
to move from computer to computer and to share the code with other
people.

In the local-filesystem case I would be choosing which modules to
include or exclude by cp'ing them into or rm'ing them from that local
directory.  In the Tahoe case I express the same choice by "tahoe
cp"'ing them into or "tahoe rm"'ing them from that directory.

I guess what I am trying to point out is that dynamic file strong
names are not *necessarily* harder to use than normal
non-self-authenticating names ("weak names"? :-)).  Maybe the current
Tahoe system is harder to use.  Maybe any such strong names system
would be harder to use.  Or maybe not -- more experimentation is
needed -- but we can already tell that such systems are not nearly as
inconvenient as we would have thought after the usability failures of
public key systems such as PGP, SSL, etc..

The Tahoe-LAFS experiment is still at an early stage (the recent Tahoe
v1.4 release has that URL commented-out).  Does anyone have any
experience or information about the practical usage of Microsoft's
strong name assemblies?  They have been around for many years as a
supported core feature of the .NET framework, which has approximately
one zillion users.  Surely we can learn something from that.  I am not
among that zillion, and I don't know how to learn from them.  My best
information so far from one .NET programmer is that you typically
deploy a bundle which contains a copy of every module you require and
you only use modules imported from your own bundle.

Regards,

Zooko
---
Tahoe, the Least-Authority Filesystem -- http://allmydata.org
store your data: $10/month -- http://allmydata.com/?tracking=zsig
I am available for work -- http://zooko.com/résumé.html