Hi Craig and all!

Craig Latta <craig.latta at netjam.org> wrote: 
> > > Instead of using files to communicate changes, I'd rather use a
> > > system which mediated a live conversation between two systems (an
> > > updated one and a to-be-updated one). A "synchronizer" of sorts.
> > 
> > This is actually what it does!
> 
> 	I look forward to having the time to try it out! :)
> 
> > ...Essentially what the slave map does when you synch is it calls
> > using HTTP an url at the master (at sqf typically or a mirror of it)
> > with it's last known transaction number as an urlencoded argument.
> > 
> > The server responds by fast searching backwards in its logfile
> > copying the recorded transactions from the log and then gzipping
> > them together and returning them... The slave map then just
> > evaluates this stuff using the Compiler, exact same technique as the
> > Module files use by the way.
> 
> 	Hmm; well, I'll have a better opinion after I've played with it, but
> that seems to brittle to me. In particular, the conversations seems too
> one-sided. It seems like there should be some way for the client to say,
> "Hey, some of this stuff conflicts with other things I've got, what do I
> do?" and for the right negotiation to happen. I run into trouble like
> this all the time with, e.g., apt-get.

Well, the design is of course "lightweight" so for starters the slave
map is simply a readonly mirror of the master.

So currently there will just not be any conflicts. :-) Do note that
SqueakMap is not equivalent with the apt system because it tries not to
step on the toes of the Modules system in 3.3a. One such area is
conflict resolving and full dependency resolution. The Modules stuff
already does (well, versions and conflicts between them is an area
needing work) this so that is not the job of SqueakMap.

IMHO SqueakMap simply answers the questions of "What is out there for me
to use and where is it?". More or less.

But sure, when it grows there will come up features demanding a "dialog"
between the master and the slave. One area would be if the Morphic
SqueakMap browser could accept registrations locally and then "send
them" to the master when synching. Currently I chose not to allow that -
the slave is simply a readonly map. But I actually think it will be
tremendously useful nevertheless!

One area (demanding more of a dialog) I have been thinking about is to
allow the slave map to have additional stuff only visible locally. Like
a company using Squeak could register packages in a local mirror map
only visible within the company and then later "publish" those
registrations if they want to.

Yada, yada... this is one reason for me to try to keep it simple - their
are simply too many things we COULD do. I instead try to do one thing at
a time according to STTCPW.

> 	Thanks for being so enthusiastic!

It's because I think SqueakMap will be crucial when:

a) Squeak grows. Even now we can't keep up. There are ENHs, FIXes,
GOODIEs flying by on the list in an ever increasing speed.

b) The new Modules system will become a big jungle (but a good one). And
in the jungle you need a Map. Hmmm, I wonder what the Compass would be?
Some form of tool showing the "direction" to your goal? Perhaps someone
could design a little tool asking questions and then gradually showing
the user what packages he/she should take a look at... :-)

regards, Göran