Le 2004/07/15, goran.krampe at bluefish.se écrivait :

Hi Göran,

>So my perception here (and Craig confirmed that) is that Craig is
>implementing a replacement of SM, and this I did *not* know about. I
>knew he was building a "module system" but since he haven't contacted me
>about how it would relate to SM I simply assumed it was at a lower
>level, like say Monticello is in most ways.

I would definitely had thought the samething as you.

>But the discussion at this point showed me that no - this was indeed
>intended as a full replacement and that his perception of SM was that it
>was a "transitional" thing. He also said that his stuff is in the
>current 1.8alpha release.

May be for Craig SM is "transitional", view from his Squat project.  But from the Squeak
community perspective, I never heard somebody expressed the idea that SM is "transitional".
I would say that SM, Monticello, where in the lasts years some of the most important tools
for Squeak and I hope that these aren't "transitional", or if they are it is not in term of
replacement but in terms of evolution (they will progress). 

>
>1. Craig can of course build whatever he likes, and I adore the work on
>Squat!

I agree

>2. Craig and I, given the complex subject and IRC as a media, may have
>misunderstood each other, even though I doubt it.

Only Craig can answer that.

>3. I am not accusing Craig of anything, even though I *can* say I was
>quite a bit surprised and did feel pretty low about the whole situation.
>I will not deny that.

I would too, remembering the 'module SAGA' (was Squeak 3.x)  where what I retain is:  a
beautifull or seductive project is useless if only one man know and understand it, and if the
community can't participate to his direction, orientation and completion.  But don't forget as
you say in (1.) that it is OK for Craig to pursue is quest.  The question is :  what consitute the
community objectives?


>- 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.
>- If the answer is yes, I will equate that to mean that you want SM to
>evolve into the future and not just be replaced with something else. For
>my future plans, see below.

Yes for sure.

>- 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 ....

It is a must, everybody can have a point of view on it even if not everybody can effectively
build it, or say what is the best way to implement something.  It is useful to know what
people think even if it is only 'I second the point of view of Karl'.

>Future plans in broad strokes
>==================================
>
>There are a few cruical parts of the current SM that I dislike:
>
>1. There is no dependency model yet.
>
>2. The synchronization of the model uses HTTP and sends ImageSegment snapshots 
>of the complete SM model down to the client, if it has been modified on the server. 
>This is both crude and forces the model to be exactly the same for all users.
>
>I have just spiced up the SqueakMap Package Loader with some needed FIXes and 
>ENHancements and some refinements to the domain model. My next immediate step is 
>to bring the server a step forward with some FIXes and features and also add the 
>server side cache and a mechanism for mirroring.

Fine

>After that I intend to add the long planned dependency model. 

That is what everybody is crying for I guess.  Is the conception of this model was discuss
earlier or will be sometime in the next months ? (sorry if it is done just indicate where to
pickup the information). In fact for now I don't have a well understanding of what this implies
and how to do it, except to say that dependency doesn't seem easy to do.

>And finally - when 
>that is done - I want to attack the synchronization mechanism adding the following 
>features:
>
>1. The ability to have local differences - like for example private packages that 
>noone else can see.
>
>2. The ability to modify the map using local code instead of going through an ugly 
>web UI on the master. This would open up all the mechanisms in the web UI to 
>local UIs inside Squeak and we maintainers can build and use tools inside the image 
>instead to make releases etc.
>
>This last part - the synchronization mechanism - is tricky.
>
>The ultimate solution would be to have a proper transactional shared object memory 
>like GemStone has. Magma is looking mightily tempting in this regard. Unfortunately 
>it is a pretty hefty dependency to add - but on the OTHER hand - it would only be 
>needed for write access to the map. All the current uses of the package loader in 
>the image would not need it, only if you wanted to do map maintenance it would be 
>needed. Unfortunately Magma doesn't have any mechanisms for doing offline work 
>today if I am correct.
>
>Now - I am all ears about alternative approaches to the synchronization mechanism 
>but remember the following characteristics of the current approach (sending a 
>gzipped ImageSegment through HTTP):
>
>1. It works through any proxy or firewall since it only relies today on HTTP.
>2. The map is shared by all other images in the same directory so when you have 
>updated it in one of those images the others will load it from disk instead of wasting 
>precious bandwidth once more.
>3. The map works just fine (readonly) even if you are offline.

Agree, these points are big values.

These was my few notes on the subject for now.

Ciao

Raymond