[ANN] DVS rev. 1.34

Göran Hultgren squeak-dev at lists.squeakfoundation.org
Sun Oct 27 10:24:51 UTC 2002


Hi Ned and all!

Quoting Ned Konz <ned at bike-nomad.com>:
> On Saturday 26 October 2002 12:57 pm, danielv at netvision.net.il wrote:
> > [A pluggable architecture for Installers]
> 
> > Right now we have several responsibilities bunched up together, we
> > might want to separate, that are all handled by the installers - -
> > Getting something from the net and saving it locally
> 
> This should be generic, no?

Well, theoretically there might be repositories that are more advanced - like
CVS for example. Then it is not just an url download. But most are, that is why
SMSimpleInstaller is a good choice for a superclass. But a CVSGumboInstaller (or
whatever) would probably subclass SMInstaller.

> > - Decompressing it
> > - Unpacking (for sar files)
> 
> I'm building a SARInstaller that will be used by the SMSarInstaller or 
> whatever. It will have more sophisticated capabilities (user 
> interaction, choosing configurations, etc.)

Cool!

> > And we want to add more logical operations on the code delivered,
> > such as -
> > - Upgrade/uninstall/reinstall
> > - 'browse code' (regular or maybe via DVS)
> 
> These would require an in-memory representation of the actual package, 
> with information that may go beyond what's in a SMCard.

That would depend on the package format - a single class or class category
fileout is pretty simple to uninstall (disregarding reversing effects of class
initialization of course). And since the installer instance installed the
package in question it could have save information about how to uninstall it. 

> > I'm assuming this covers more or less what we'll need soon. Any
> > other ideas?
> 
> Conversion between formats: take a DVS or ChangeSet and put it out as 
> a SAR, etc. Build a .pr from several other packages and an existing 
> .pr. Make a full installation script from a group of packages.

Hmmm. Grouping packages together seems to me to defeat SM a bit. If we intend to
move further onto "3.3a Modules hometurf" (which is a decision we need to
address IMHO) then I would rather start thinking about adding support for:

1. Multiple card versions (and thus versions of packages)
2. Configurations/dependencies between packages

But again - now we are really beginning to reimplement stuff that Modules does.
I would like to have some form of decision about this because I wouldn't like us
"lightweight SM/DVS hackers" to be pointed at and called "Forkers! Forkers!" :-)

> > when generating the menu for a select package, we do a
> > (services select: [:service | service canHandle: aSMCard]) do:
> > [:service
> 
> As Avi was saying, how do we tell whether a given package can be 
> handled by a given installer? Until we've downloaded it and can 
> inspect it, we don't know (for instance) that a .st file is a DVS or 
> plain Smalltalk file.

Categories! I think that is the correct way of dealing with this sort of thing.
It is exactly what they are for! (wrote about it in another post answerinv Avi)

> And what about situations where someone provides multiple formats 
> (like a .pr and a .sar), or changes format from one version to the 
> next?

Multiple formats... Well, I have been thinking about adding "links" to an SMCard
- other interesting urls that is. And also "attachments". Links would perhaps
mostly be used as pointing out a Minnow page, good documentation sites etc.

And attachments could be used for .pr files or for example "sample documents"
that the package can handle.

> Could the SMCard record formats as well? This could simplify things, 
> though it doesn't provide for having multiple formats for a given 
> version.

Yes, I also thought in that direction, but perhaps Categories would be better.
Otherwise we risk having the registerpackage/updatepackage Forms to become too
large and confusing.

> > Services register when their class is installed, so people can
> > freely add SM packages that implement new package handling
> > services, including handling new card types, such as .pr files.
> >
> > How about it?
> 
> Sounds good to me.

Yes, very good.

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