An uncomfortable question

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Fri Oct 25 07:42:12 UTC 2002


Hi David and all!

"David T. Lewis" <lewis at mail.msen.com> wrote:
> On Thu, Oct 24, 2002 at 11:33:40AM +0100, goran.hultgren at bluefish.se wrote:
> > 
> > So... have you tried SqueakMap RC1? ;-)
> >
> I will do so soon, hopefully this weekend if I have some free time. It looks
> very useful based on your web pages, and I like the keep-it-simple approach.
> Dave

Thank you for the kind words.

And now it's not only me moving SqueakMap forward, I have gotten company
by Daniel and Ned which makes it all much more promising! Developer
mindshare is very important - a lesson learned over and over in the
OpenSource world...

SqueakMap sofar has been designed and implemented with simplicity in
mind, there are numerous examples:

1. Registering a package is done using ONE web form submit. Nothing
else. For this reason I avoided creating "accounts" in SqueakMap because
then you would have to register as a user first which would make the
threshold higher.

2. The distribution mechanism is based on a simple transaction count
scheme. Simple but effective - and we can actually make it much more
efficient - but I haven't bothered yet. Currently every small change in
a registration will save the whole registration as a new transaction. We
could instead save only the changed fields.

3. The choice of storing the passwords as SHA hashes inside the map
means that a client map can be identical to the server map. This is also
the reason why SqueakMap can't tell you what your password is - it
simply doesn't know.


And now seeing that this little baby is really starting to fly I have
also realized that:

- Much of the success with SM has to do with it being "backwards
compatible". It offers new mechanisms without shutting the door in your
face if you don't use the super-mega-new-special-format.
- It only tackles a part of the problem: The catalog of packages. It
doesn't and will not (as long as I have some leverage) try to tackle
namespaces, source code management or module analysis.

To be fair though it *has* established a namespace for packages - each
package is required to have a unique name. But the name is allowed to
change - the package has a UUID.

And it *has* code for installing packages in different formats - so in
this respect it covers both package installation ("dpkg/rpm" in the
Linux world) as well as package cataloguing ("apt-get/urpmi" in the
Linux world). But on the other hand, the installers are "pluggable" so
if anyone here has a package format you like for Squeak code that isn't
supported yet - help out and add a subclass of SMInstaller. :-)

For example, one of the most important formats isn't implemented yet -
the .pr format (Project). This is also because I wasn't sure it should
be considered a "code package format". Perhaps it is more of an
"attachment" thing for packages?

Enough blabbering, regards Göran

PS. Yes, we need to fill the page on minnow about SM... Perhaps someone
could help out writing a good introduction? DS



More information about the Squeak-dev mailing list