About SqueakMap for 3.2 and the future!

Göran Hultgren goran.hultgren at bluefish.se
Sun Oct 27 19:06:55 UTC 2002


Hi all!

Now that RC2 is out and it seems to work (knock, knock) I would like to start a
period of "thinking" about what to do next. In fact, OOPSLA is coming up and I
think we should let the package "SqueakMap" be as it is right now. SMLoader and
Browser can of course evolve furiously, they are "just UIs". :-)

So, let's only correct bugs in package "SqueakMap" and not add features -
feature freeze in other words. This can hopefully let Scott Wallace (with our
help of course) get it into 3.2. And when I am talking about that, some small
issues:

1. Category name. Currently it is called "SM-domain" but that doesn't say much.
Perhaps "SqueakMap-Kernel" would be better or something?

2. The postscript for the RC2 changeset marks "SqueakMap" as installed (in
SqueakMap itself) and installs "SM Package Loader" (through itself) which means
that it will get the newest release *at the time when the image gets updated*.
That is probably not want we want in the update. In fact, if we now put RC2 into
the update stream and in a year SM has evolved away from RC2 making it
incompatible with the master then when someone updates an old 3.2 it will... Oops.

Perhaps the update changeset should just include a little snippet similar to the
one that I have been posting for trying out SM? I could even add a little
feature in SM that can deliver the download url for a package using a simple
http request. I could make it look something like this:

ChangeSorter newChangesFromStream:
(('http://map2.squeakfoundation.org/sm/packagebyname/squeakmap3.2/downloadurl'
asUrl retrieveContents content) asUrl retrieveContents content unzipped
readStream) named: 'SqueakMap 3.2'

And then we register a package called "SqueakMap 3.2" which will "always" work
with 3.2. And then the postscript can still install "SM Package Loader" like it
does today since it will be compatible. Neat.

So Scott and Doug - if you could just review RC2 (especially the changes to
classes without the SM prefix) and give it a "green light" then I can produce a
changeset described above that could go into the stream.

---------
Ok, what about the "thinking" part?

Currently there is an interesting situation in the Squeak community and Andrew
Greenbergs post called "An uncomfortable question" brought it up, even though it
has been discussed quite a lot in the different modules related threads actually.

In short we have a 3.3a with the "Modules" code in it that noone seems to work
on currently and then we have the "lightweight modules" route which has
materialized itself the last months consisting of primarily DVS
(http://map2.squeakfoundation.org/sm/packagebyname/dvs) and SqueakMap
(http://map2.squeakfoundation.org/sm/package/4f0b9db6-8add-43aa-8d6b-53e6a0ea8442)
but also other tools like Spaghetti tracer
(http://map2.squeakfoundation.org/sm/packagebyname/spaghetti) etc.

Currently SqueakMap doesn't overlap the "Modules" code. Yet. The intention was
all along that SqueakMap should fit nicely on top of Modules but still being
backwards compatible in regards of being able to handle packages not in "Modules
form". But now we have reached a point where we want to add features/functions
that clearly will solve problems that Modules was meant to solve (think
dependencies between packages etc).

*Personally* I have come to the conclusion that Modules in 3.3a is dead. I tried
to fool myself into thinking that it could get picked up by the rest of us but
after having seen Andreas and Daniel struggle and more or less "give up" (I may
be wrong in this but that is my perception) then... ;-) I have a hard time
seeing anyone else succeeding.

Again *personally* I think we should just face this truth, declare 3.3a as a
dead branch, start harvesting as much as possible over to 3.2 from 3.3a (forming
3.4a?) and then try to look over the stuff in Modules and see what we can easily
copy or learn from it. During this we should start ripping out pieces of 3.2 (in
3.4a that is) into packages of their own in SqueakMap. Using DVS and SqueakMap
this is clearly possible today.

So, I would like to come up with some answers to these questions:

1. Should we dump Modules? If not then how do we make Modules work?
2. If we dump Modules, what do we do with 3.3a? Is it even possible to
reconstruct it easily? Is it better to simply freeze and salvage stuff from it?
3. If we dump Modules, how do we proceed with the lightweight route?

I know that we haven't reached any answers to 1 and 2 yet, but just for the
argument - what about question 3?

Well, here are some top priority items in that case:

- Add support for programmatically registering packages and updating packages
Currently these two activities can only be performed using the web UI on the
master server. But the design of SM allows us to improve this and this would
really make life easier on the package maintainers (but users wouldn't notice
any difference of course).

- Add support for versions of registrations (SMCard).
We need this for several reasons. Especially if we want to be able to handle
dependencies between packages. Currently SM only knows about the latest version
of a package.

- Add support for registering optional "incoming" and "update streams". Or
something similar.
This is to support users sending FIXes and ENHs etc "to a package". If a package
does not define an incoming ftp/http upload area etc then it can fall back on
email if the maintainer expressly allows that.
Packages using DVS could of course do their own thing with a CVS backend. But
developers that want to work with changesets need this to keep track of
contributions etc.

- Add support for configurations/dependencies
Now we are really stomping into the "Modules" arena. Daniel wants to think in
terms of publishable "configurations" instead of registering dependencies
directly "on the packages". I am also leaning in this direction. Either way,
this is a very interesting area to discuss further. We need this in order to be
able to let users install packages that depend on other packages. Just try
installing Spaghetti tracer and you will realize it depends on DVS, and so on.

- Separate all UI from model (the code is a bit dirty right now)
The SqueakMap model should of course be totally clean of UI code. It isn't
today, but we will fix that.


Then we have other nice things (and tons more floating around):

- Free text search (Scott's engine)
A nice free text search mechanism in SMLoader/SMBrowser and the web UI is of
course a perfect addition that will make it much easier to find packages. And we
have a nice engine for this in harvesting land somewhere... ;-)

- Annotations
This is my catch-all mechanism for bugreports, comments etc on packages. I am
not sure if SM should handle this or if we are in fact talking about a separate
system.

- Swikification of texts in registrations
I have actually a reimplementation of the Swiki-syntax that is completely
"separate" that we can plug into SM!. This would make it possible to link to
other packages using just their name, embed urls in text, bullet lists and much
more. We just need a Swiki-syntax->TextMorph-thingy but that couldn't be too
hard to hack into my Swiki-code.

- Integrated upload capability for package storage or attachments to packages.
Well, SM is a catalog of course... so... should it offer storage?

Anyway, a long post. Sorry.

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