Hi all!

Quoting danielv at netvision.net.il:
[SNIP]
> > 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
> :-)).

Hmmm. Perhaps. Or simply stuff SMSqueakMapBrowser in there, it's not that
complicated is it? :-)

An advantage would be minimizing confusion - since newbies will be involved etc
it's good if there is one single tool for this (and that it is sufficiently good
of course). Personally I am simply hoping that the SMSqueakMapBrowser will wake
people up and say, "Hey, this SqueakMap is actually really cool! Let's put it in
the image even though 3.2 is released!".

It would not really be such a big deal because it doesn't change much of the
image so things will very unlikely break.

> 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

I agree. I have simply not lobbied that hard since it is still "beta".
It is shaping up pretty good though.

> 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

Yes, I have defined the major Squeak versions as an attribute.
Perhaps we could add a field "Updatelevel guaranteed to work (=development level
or tested lowest level)" to the packages?
A simple check that the image is after that level would perhaps be nice.

> 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 ? :-)

Yes! :-) I do. It has been a bit sleepy the last weeks because of two major reasons:

1. I have an assignment right now. :-) Yiha.
2. I want to get a bit further down the feature list before I really start
banging the drums. Keyword searching, category filtering, minnow-synching of
initials, zip-file installation, recent changes etc.

> IMHO this is so far beyond where we are now, it's a good enough reason
> to have a 3.2.1. 

Well, we could at least pop it into the update stream for 3.2.

> 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 

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

No, I agree. I am aiming both for the good old Squeak versions and the new world
in 3.3. Actually, I would like SqueakMap to work for even older versions than
3.2 (and a while there I was aiming at a MVC UI too but...).

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

I agree.

> [Allow lightweight modules (aka system categories + class extension
> method categories) to be easily uploaded and updated in SqueakMap]

I will take a look at Avi's code and begin to think about add/updating package
entries from within the SMSqueakMapBrowser.

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

:-) Well, you have all the code... Kidding aside, I think the add/update will
work approximately like this:

1. SMSqueakMapBrowser creates a new (or updated) entry locally and adds it to a
collection of "upload these entries later".
2. When the user press "commit" or something the browser will try to commit the
new entries by a single compressed HTTP call using the same logformat as the map
uses today for synching with the master.
3. The master will be able to reject the commit if there are any conflicts
(=entry has changed since then or category missing).

Well, something like that. It's not that hard to implement actually. I would
guess the most work will be in the morphic UI...

The actual upload of code is not something the SqueakMap does - but I could
perhaps hook in code from Avi (or Modules for 3.3) to do it from within the
SMSqueakMapBrowser. Or something.

> BTW, keep up the great work - we need this.

I agree. :-)

regards, Göran

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