Hi all!

Colin Putney <cputney at wiresong.ca> wrote:
> On Feb 11, 2004, at 3:40 PM, Avi Bryant wrote:
> 
> > I guess the question is whether we want to continue having the 
> > ChangeSet as the One True Format that gets to go into the update 
> > stream (and convert everything else to it, like the MC->.cs transation 
> > service that Marcus suggested), or whether we want to allow for the 
> > possibility of alternate update formats.  Obviously we have to have 
> > support in the image for any formats we put into the update stream, so 
> > we shouldn't be too loose about what we accept.  But if a lot of code 
> > does start appearing in a certain format (.sar, .mcz, maybe Rosetta 
> > somewhere down the line), I don't see a problem with allowing it into 
> > the stream.
> 
> I think the update stream should continue to be change sets only.
> 
> What we need to work on is making other update mechanisms equally easy 
> to use and creating distribution images that contain code not managed 
> by the update stream.
> 
> In other words, the update stream should continue to be change sets 
> only, but it shouldn't be the One True Mechanism for distributing code.
> 
> Colin

Yes, I agree. The update stream should stick to changesets - no point in
messing with that. :)

Regarding putting code into the stream or putting SM install commands
into it:

Personally I think we should use SM install commands. Since the update
stream = Basic we will only issue such installs of packages that we
consider to be part of Basic (not Minimal, remember?). So these Basic
packages should of course be taken extra care of - releases that we
issue commands for as updates should of course never be deleted nor
mutated. And we will of course only issue installs of specific releases
so that the update will always result in the same thing.

When the update is loaded the install command needs a local map in the
image. In future distributions of Squeak we should IMHO include such a
map. This means that the result of the install command is a single URL
access directly to the package file. What I mean is that the SM server
program is not involved at all. And if Squeak has been distributed with
a preloaded cache then there will be no Internet access at all, except
for the update itself of course.

SM is currently hosted at squeakfoundation.org. Cees has good facilities
AFAIK. I am not sure where the update stream is today. We can also have
a policy that says that Basic packages should be stored at SqF too - so
that we don't have to rely on flaky servers (though that will not be a
problem when I put the server side cache into play).

Note: If people upload files to SM using the file upload mechanism in
the web UI, then the files are served by the Squeak SM webserver. Though
in my experience SM has been pretty rock solid so far.

And finally, regarding MCInstaller and VersionNumber - personally I find
these to be perfect "Basic" packages. They are small and non-intrusive.
And MCInstaller will very likely be needed for many, many of the
installs from SM anyway.

Monticello is larger and should probably be installed "on demand". We
can include it in Full if we like, but I also intend to put out a new
version of the package loader which includes some "smarts" to tell
people that they need to install it first when upgrading a Monticello
package.


regards, Göran

PS. I have a big fix for FileUrl that I am working on, it is in BFAV
(Text in title: *Scamper does*) and need reviews - and I want to fine
polish it a little bit more. This FIX makes Scamper work in 3.6 and 3.7
and also cures the FileUrl so that it actually complies with RFC1738,
yikes! :) Since FileUrl has been a bit "weird" IMHO I need people to
look into this fix - at least to file it in and then use Filelist with
FTP etc, ServerDirectory yaddayadda. No, I haven't rewritten the whole
Url morass, but it is a little start in one corner.