The future of SM...

Avi Bryant avi at beta4.com
Mon Jul 26 19:10:54 UTC 2004


On Jul 25, 2004, at 10:14 AM, lex at cc.gatech.edu wrote:

> Let me give some specific examples.  Here are some things that should 
> be
> doable at a local level, without involvement from any central 
> authority:
>
> 	1. The creation of new universes that draw packages from an existing
> one.  The local guys should not have to coordinate with the server you
> are drawing from.
> 	
> 	2. The creation and maintenance of user accounts.  Individual
> organizations should be able to have their own accounts without
> publishing them publically.
> 	
> 	3. The designation of who has permission to post package versions to
> each server.  Particular package universes should have their own rules
> about this, that even the original owner of a package cannot 
> necessarily
> override.  (Even though in the main Squeak repository, we want to give
> more deference to the designated package owner.)

I'll note that these are all things that are currently doable on a 
package by package level, using Monticello repositories, even if not at 
the SqueakMap level.  I wonder if one solution to this argument about 
distribution vs. centralization might be to factor the model such that 
SqueakMap is only responsible for those aspects that we all agree 
should be managed centrally, and use other mechanisms (Monticello, 
update streams, Squat) when we want to be more distributed.  I 
certainly agree with your three examples - that's why Monticello was 
designed to the way it was.  But I also agree with Göran about the 
benefits of having a single, central repository of metadata - it's just 
so valuable for someone to open a Package Loader in a virgin Squeak 
image, without having to do any configuration, and have one-click 
access to essentially any package anyone has released for Squeak.  But 
we could still have SqueakMap as the central source of information 
about which packages exist, and have it point the user to the 
repositories that have information about specific versions (that have 
been released in a non-centralized process by various people at various 
organizations).

To put this another way, what SM does, and does very well, is to act as 
an entry point: it lets the user get from "I wonder if there's a 
package that does X" to having a URL for that package.  As Göran says, 
it's a catalog.  But it's fairly relaxed about exactly what it is that 
it is cataloguing.  There's no reason that URL has to point directly to 
a particular piece of code; it could be a URL to a directory full of 
package versions that were managed totally separately from SM.  One 
could, for example, abuse the list of SM releases for a package to 
instead act as a list of sources (and leave the password open so that 
anyone could add one).  Then you just need the right code in the image 
to use that data in appropriate ways.

Avi



More information about the Squeak-dev mailing list