The future of SM...

Avi Bryant avi at beta4.com
Thu Jul 15 18:32:07 UTC 2004


On Jul 15, 2004, at 6:22 AM, goran.krampe at bluefish.se wrote:

> - Does the community want me to continue my work on SM? If the answer 
> is
> no, I will drop it immediately, I don't have time to waste on a dead
> project.

Please, please continue it.  With all due respect to Craig: it would be 
madness to stop working on a successful piece of Squeak infrastructure 
that we've all come to rely on, simply because somebody thinks that 
they may have a better alternative ready at some unspecified point in 
the future.  Slate is very promising, for example, but we haven't all 
given up on Squeak just because Brian's working on it.

> - If the answer is yes, is it fair of me to ask people to collaborate
> with me on how SM works and how it should evolve instead of people
> building replacements?

To turn your question around: I don't think it's fair to ask that 
nobody work on building replacements.  Sometimes visions and goals are 
too different for collaboration to work.  That's their prerogative, and 
if they come out with a real competitor to SM, the community will 
benefit in the long run.  The community will *not* benefit from SM 
disappearing at the first sign of competition.

I also think it's fair to ask that those who *do* share your vision 
closely enough that they can reasonably collaborate on SM, do so.  But 
that won't include everyone.  That's how it goes.

> In fact - the coolest thing would be if someone could build me a 
> mechanism which can take an instance A (of SMSqueakMap) and an 
> instance B and then compare them and figure out the differences. If I 
> had that - then a user could do local modifications to the map - say 
> add a new release of a package - and then "commit" them to the server. 
> It would first compute the differences made by comparing the current 
> modified map with the latest snapshot on disk - and send the 
> differences over the wire to the master server. The master would then 
> either say "No conflicts, committed" or "Conflicts detected - they are 
> these" and the user would have an opportunity to undo selected 
> conflicting changes and try to commit again.
>
> So... I want a smart Smalltalk diff/patch but for *objects* and not 
> Strings. Anyone up to the task?

Colin has already pointed out that diffing objects is, in the general 
case, very hard, and that he's working on tree diffing.  I'm pretty 
certain that the SM model could be squeezed into an appropriate tree 
for his Difference Engine to work with it.  In fact, the model is 
probably simple enough that we could support it with the current 
version of Monticello: people could load/commit/merge versions of the 
map (the data, not the code) using a special set of MCDefinition 
subclasses.  It would take a reasonable amount of work, but would 
certainly be doable.

> Hmmmm... I might have an idea how to do this in a simple way... Well, 
> that is another posting alltogether. :)

Eager to hear it :).

Avi




More information about the Squeak-dev mailing list