SqueakMap RE: [Modules][Fix] Reloading VMConstruction + others

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Mon May 13 12:09:05 UTC 2002


I don't know about the CC but I kept it, sorry if this mail is a bit
confused, I wrote it in a hurry. :-) Just ask if something is unclear...

"Andreas Raab" <Andreas.Raab at gmx.de> wrote:
[SNIP]
> Also, (and that's not directly to you but to anyone working in this
> area) has there any progress been made on the front of providing an
> understandable user model and programmer interface for modules?! Since

AFAIK Alexandre Bergel has a tool for browsing loading etc. The
screenshots looked good! :-)
Url: http://minnow.cc.gatech.edu/squeak/2362

And I am working at home on something I call SqueakMap which is a
catalog system for Squeak.
It is not what you asked for but I take the chance to tell about anyway.
:-)

I include a zipfile with it all, just do a file-in on sminstall.st - it
will load all the other changesets. This includes Comanche, a ConfigFile
implementation, The HttpView framework, our Fixes and SqueakMap. Then
you can look at the class comment of SMModule to play with it - two
simple doits are there.

BEWARE: Cruft is in there - this is just a snapshot in "mid air" - NOT a
release. I got a bit nervous from not having posted this yet...

The plan is this:

1. We install a SqueakMap master server at squeakfoundation.org. This is
just a Squeak running as explained in the class comment of SMModule.
This gives a web interface for the SqueakMap. The SqueakMap itself
maintains it's state in a single logfile and does an open/close on each
operation so nothing should get lost. On restart it reloads the file
etc.

2. Install the same code in each Squeak. Create a "slave" instances of
SMSqueakMap and let it load itself from the master. It does this through
method SMSqueakMapView>>updatesgz which means that we should be clear of
firewalls. In essence the slave just uses a normal HTTP request with
it's last known transaction number as a parameter and get's a gzipped
partial logfile with only the new transactions back. This will make a
sync operation very fast. The slave instance also maintains it's state
in a logfile (which can be compressed, see #saveNewLog). So if you loose
the image it will still be available (and perhaps we can add logic so
that it can be available to multiple images at the same time even).

Now people can go to SqueakFoundation and use the webinterface to
register Squeak code packages (not restricted to modules). But we can
also add this capability to the Squeak tools so that it can be done from
within Squeak of course. A search interface should be available at
SqueakFoundation but also even better locally from within Squeak in the
slave map - then there is no networking needed at all - I want to use
Scott's search engine for searching btw. And the slavemap is updated
incrementally as described above so it is always "up to date" - this is
like "apt-get update" in Debian but even more efficient.

What does the SqueakMap hold then? I want it to hold 3 things:

1. SMCards. These are simple cards, one for each package. Anyone can
register one.
2. SMCategories. These are "categories" which the cards can "belong to".
A few selected maintainers should maintain these so that chaos doesn't
ensue.
3. SMServers. I haven't does this one yet but this one is ESSENTIAL. The
idea is to map a Squeak module (as in the new modules system) to a
"repository" (=server). I want people to be able to register their own
ftp-server as a "node" in the virtual module hierarchy. So when you try
to resolve #(Squeak People gh) for instance, you first (after having
failed the check in the cache) check in the SqueakMap and hopefully find
out that you should go to ftp://marvin.bluefish.se/gh/squeakcode/ (or
whatever).

Number 3 should make our global module system fully resolvable. Note:
The SqueakMap could optionally "harvest" SMCards since it knows the
module path. This way the SMCard info could be stored in the .def file
in the module itself and the SqueakMap would just mirror that.

Well, what do you all think?

I will sit down and try to finish this in some usable state in the next
few weeks. I just need to release another internal project here... :-)

regards, Göran
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sm.zip
Type: application/octet-stream
Size: 64140 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20020513/02611099/sm.obj


More information about the Squeak-dev mailing list