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