SqueakMap

danielv at netvision.net.il danielv at netvision.net.il
Sat May 18 16:45:21 UTC 2002


Aha! that sounds wonderful! I haven't looked at the code because my
weekend is ending and I just now realized the importance of this. Please
make a pre-release with a small usage sample as soon as you can...

That sounds like almost everything critical that's missing to give
Squeakers a wonderful distributed configuration system (that and the
sound of Squeakers busily taking the image apart... ;-)

Number 2 could be used to choose a configuration. If we make
SMCategories composable (Composite pattern, can include other
SMCategories), I can make my own config = Gorans config + Whisker, which
would be very, very cool. 

Especially if Categories can include a maximal version (Goran's config +
whisker 0.92, because that's known stable enough to my taste (just an
example)).

Daniel

goran.hultgren at bluefish.se wrote:
> 
> --Boundary_(ID_YDfibRhHDN87l4BXlhMUQQ)
> Content-type: TEXT/PLAIN
> Content-transfer-encoding: 8BIT
> 
> 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



More information about the Squeak-dev mailing list