[Modules] Braindump!

Henrik Gedenryd h.gedenryd at open.ac.uk
Mon Feb 18 15:10:38 UTC 2002


Two U:s have decided to start blocking traffic in the same week, and I'm
still trying to receive my squeak list normally again, bear with me if I
overlook something, send it to me privately if I seem to have missed
something between Thursday and today (Monday).

> Streams/releases
> ================
> 
> Squeak: Well, currently we have something similar - but we lack the "module"
> granularity which has
> made it problematic to maintain the gamma and the offical relase ("stable" and
> "testing").
> Eventuall we all end up in the alpha stream! :-) This is not so good, but I
> think it would be much
> simpler if we where dealing with new versions of modules instead of with small
> changesets.

I posted my ideas on this a while ago. I'll try to find it and repost it now
that interest may be catching up.

> Conflicts
> =========
> 
> Debian: Each package (specific version) can name explicitly other packages
> (specific versions)
> that it is known to not be able to coexist with.
> 
> Squeak: ?

The above sounds fair, we'll have to see what needs arise, I think.

> Basic metainfo
> ==============
> 
> Debian: I don't have it in my head, but each package has a set of basic meta
> information like
> author, homepage, short description, long description etc. Take a look at
> http://packages.debian.org/stable for examples.
> 
> Squeak: ?. We should also define such a minimal set of metainfo that each
> module should have.

There is an annotations facility, but nothing is done with it yet. It would
be really easy to have annotations stored (and loaded) with the module .def
file.

> Cache of packages
> =================
> 
> Debian: All packages are downloaded and cached on the machine.
> 
> Squeak: Henrik talks about a local cache of modules so I think this is
> accounted for. I am not
> sure though.

Yup, there's a local cache.

> Cached database of package info
> ===============================
> 
> We need something like this I think. And, to be concrete:
> We should define an offical list of "top servers" (but you could add your own
> of course, compare

> An example: Let's say I have a module #(People gh sqcvs). One way would be to
> store my stuff on
> one of the top servers (probably at SqF). But I would also like to just stick
> a "forwarder" there
> at "gh" which says that, "Hey, gh is not here. He has his modules over there:
> ftp://ftp.bluefish.se/gh/".
> Then if someone tries to load #(People gh sqcvs)
> Squeak would:
> 
> 1. If no cached info is available at all: Visit the "top servers" one by one
> and load their
> index-files (just like "apt-get update" does in Debian) and store this in a
> local database
> structure.
> 
> 2. Check the database for the module #(People gh sqcvs). If not found, back
> one step up and look
> for #(People gh). This would resolve to an url, say:
> "ftp://modules.sqf.org/People/gh". Then we
> load "ftp://modules.sqf.org/People/gh" and voilá! We find a forwarder to
> "ftp://ftp.bluefish.se/gh/". We go there instead and since it is a new
> location we load the

> The scheme above would mean that we can, by placing a forwarder at a "parent"
> server - make a link
> to another ftp/http server on another machine and still maintain the virtual
> hierarchy of modules.

There are already provisions for this. As it is now you have to send an
ftp:http: message or similar to a repository object to point it at a
different location. A hopefully small amount of work would allow this
forwarding to happen automatically.

You still have to convince me about the need for replicating contents across
multiple servers, as opposed to having only one server _per module_, but
allowing different servers to hold modules. Once and only once seems like a
very useful principle here, especially given the size of the Squeak
community! The added complexity for handling replication, and the
possibilities for subtle bugs, all seem not to be worth it to me.

So to be clear I think there are two issues here: 1. Different modules on
different servers, yes it's virtually there already. But 2. replicating
module servers: Do we really need it? I think it can be put off until we
would need it. 

Henrik




More information about the Squeak-dev mailing list