[ANN] DVS rev. 1.34

Ned Konz ned at bike-nomad.com
Sat Oct 26 21:12:51 UTC 2002


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?

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

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

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

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

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

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

> 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.
-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE




More information about the Squeak-dev mailing list