[ANN] DVS rev. 1.34

Göran Hultgren goran.hultgren at bluefish.se
Sat Oct 26 18:15:42 UTC 2002


Hi all!

Quoting danielv at netvision.net.il:
> Avi Bryant <avi at beta4.com> wrote:
> > 
> > On Sat, 26 Oct 2002 danielv at netvision.net.il wrote:
> > 
> > > Filing in via DVS will also remove methods?
> > 
> > Yes.  The whole point is that it brings the package in the image in
> sync
> > with whatever's in the file out - by adding, changing, *or removing*
> > methods to do so.
> Cool. That makes it quite a bit better than what we have now, in terms
> of filing things in, whether for comparing version or for updating
> packages, because it should prevent messes like we had when SqueakMap
> had some an implementation of #unpack removed, but people updating got
> both versions.

Yes, sorry about that... I am no expert in dealing with ChangeSets and I think I
wrongly did a "trim history" and then it went boom...

As I have said now for a long time - ChangeSets are good for recording history
but not for deployment/distribution. IMHO. But DVS might change this! :-)

> > > if so, I need to start using
> > > it for my packages. Are you going to create an SMDVSInstaller?
> > 
> > Yes, I probably should.

Yes, please! :-) Just subclass SMSimpleInstaller and go.

> I wrote a message about refactoring SM, saying I though installers are
> just a subset of code handlers that should be usable on the information
> provided by SqueakMap, and that the collection of handler should be
> pluggable, so that new handlers should show up in the tools easily.

Yes, I agree with keeping SM as open as possible for new formats etc.
Just hit me with concrete ideas. Today the installers are pretty pluggable but
of course we can use some other architecture than simple "subclass scanning"
that I do now for the installers. (We can't install .pr files today... Anyone?)

> This would allow, for example, to plug in variants that update using
> DVS, and variants that warn you when updating a package will revert
> modifications made by yourself to a package.
> 
> What do you think?

Trying to keep things "simple" (a relative term of course) I have thought of an
installer class as capable of a few basic actions:

-"download" (bring it down but don't touch the image - typically this is easily
done for single-file packages using an url (and this is inherited from
SMSimpleInstaller for free) but it is still up to the installer)
-"install" (bring it into the image)
-"upgrade" (install a newer version on top of an old one - currently this
defaults to the same as "install".)

And I have also been thinking of adding (in future SM):
-"uninstall" (wipe it off it you know how to)
-"reinstall" (make sure the end result is as if I just installed it for the
first time)

Of course these last actions will not be available for some formats. The
installer will just have to tell us if it knows how, this is how it works today.

I am not sure if these actions are the ones we want as "possible actions" but in
any case I would prefer to have them in one class (for each package type) - a
subclass of SMInstaller. You know - KISS.

Note that currenly a registration in SM does not say what format it is packaged
in - we rely on file extensions on the download url. We also do not currently
handle multifile registrations - but personally I think we shouldn't, a package
should be ONE FILE. Just use a .sar if you need more of them IMHO and if you
still think it would be nice with multiple downloads then you should probably
split the package into multiple PACKAGES instead.

regards, Göran


Göran Hultgren, goran.hultgren at bluefish.se
GSM: +46 70 3933950, http://www.bluefish.se
\"Department of Redundancy department.\" -- ThinkGeek



More information about the Squeak-dev mailing list