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
|