Henrik Gedenryd <h.gedenryd at open.ac.uk> wrote:
[SNIP]
> > 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.

I have sketched more on this in the other post "[Modules]One more idea!"
- it may be a bit hazy...

[SNIP]
> > 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.

Yes, I noted that. I have a proposal that I will post very soon.

[SNIP]
> > 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.

Ok. I also saw that it would be possible, you also mentioned it in the
class comment
of Repository class (I think).

> 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

Eh, I don't think I argued for that. Did I? :-)

> allowing different servers to hold modules. Once and only once seems like a
> very useful principle here, especially given the size of the Squeak

I agree fully.

> 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. 

I am not sure how I got you two think I wanted item 2. Perhaps you where
puzzled
by the index-file stuff I tried to describe. Do elaborate.

> Henrik

regards, Göran