SqueakMap

stephane ducasse (home) ducasse at iam.unibe.ch
Sat May 18 18:02:39 UTC 2002


Hi Goran

I do know if I get everything rigth but this looks interesting. Continue.

Stef
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