SqueakMap tommorrow?

danielv at netvision.net.il danielv at netvision.net.il
Mon Sep 16 17:57:28 UTC 2002


goran.hultgren at bluefish.se wrote:
> danielv at netvision.net.il wrote:
> 
> I have added download/install capabilities in SqueakMap but not released
> it yet.
> I can probably do such a release today. The idea is that it handles gzip
> decompression and filein of changesets and also decompression and
> installation of a zip-package as long as that zip-package complies with
> the simple rules that Ned Konz outlined earlier.
> 
> This stuff is almost working now - I should be able to fix it and
> release today.

Cool.

> But note that 3.2 is released 
What I am saying is that we need a really small, simple client in the
image, allowing people to download new packages in a trivial manner. The
first thing they can d/l is a smarter client.  This is like dselect in
Debian, now it's mostly a good way to download Aptitude (I like aptitude
:-)).

But however simple it is, it doesn't really help people if it's not in
the image. Consider the state we're in after both scenarios I described
work - it is suddenly as easy to load an external package as it is to to
run and internal one (assuming it's in good state and meant for your
image, and SqueakMap can check those reasonably well). It is suddenly
trivial for people to publish their new packages in a manner that will
be accessible to everyone.

Do *you* remember how important this project is ? :-)

IMHO this is so far beyond where we are now, it's a good enough reason
to have a 3.2.1. 
 
Of course, if people disagree, I would like to keep a stock 3.2 + basic
SM as I describe it (more or less) on my hard drive. Though in 

> and that 3.3 will be "a different beast"
> when we have Modules.
I don't think we should wait for that to happen, the important benefits
of modules to the community are already within reach for 3.2. We can
already file out modules with their class extensions thanks to Avi, we
have the beginning of analysis tool to tell us when a module is properly
defined, and SqueakMap could allow us to share code effectively with
very little extra work.

I think this is a great opportunity.

[Allow lightweight modules (aka system categories + class extension
method categories) to be easily uploaded and updated in SqueakMap]
> Yes, I have an intention to let the Modules themselves (optionally)
> contain the information that SqueakMap needs and in such a case we would
> just issue a simple "update module X" to SqueakMap and it could fetch it
> all itself straight from the source.
Why wait until we have explicit modules? if you could publish the
interface allowing one to register a new package/update it, we can make
uploading and updating SqueakMap trivial tommorrow.

BTW, keep up the great work - we need this.
 
> regards, Göran

Daniel Vainsencher



More information about the Squeak-dev mailing list