Hi Dave,

I think I sent you an mail saying that
I had switched to your package version, but apparently I didn't actually
get around to doing that on the server.

No worries, my main question was about whether you had "changed your mind" about /ss.

I looked at this again a couple
of days ago so that I would respond to Tim's question about VNC and I
realize that although we did merge the code, I never did actually
activate the final version on squeaksource.com.

Unfortunately this turns out to be a good thing, because although the
merged version runs fine, it does not seem to work properly when
restarting a saved image.

If you would like to take a look at it that would be great. Install
update.sscom-dtl.5.mcm in a clean image and work from there. You
should be able to save the image, restart it, and everything should
still keep working. Then try loading whichever package version you
are using in the source.squeak.org image and see if it still works.
There should be no errors or debuggers opening when you restart the
saved image.

The /ss code relies 100% on its code versioned in MC packages, and has zero dependence on image state. This was the #1 primary design goal in the 2011 upgrade. Loading the /ss code on top of the sscom-dtl code was never tested or expected to work. Instead, the initial image should be saved ONLY with the Personal SqueakSource code loaded, and NO servers started (RFB or web).

Then, the command-line to start the server should simply specify to use SSImagePersistence in the run.st script, like this:

____

Smalltalk run:
[ : webPort | MCHttpRepository clearCredentials.
Smalltalk mitigateIfHeadless.
webPort ifNotNil: [ SSRepository port: webPort asInteger ].
(FileDirectory default fileExists: 'logo.jpg') ifTrue: [ SSFrame makeLogo: (FileDirectory default fullNameFor: 'logo.jpg') ].
SSRepository
storage: SSImagePersistence new ;
startServer: true ]

____

SSImagePersistence uses a Promise and ensures the image is saved with the server and domain and safely restartable. I tested with a full copy of squeaksource.com several years ago.

For extra safety, we might consider using a SSCompositeStorage composed of an SSImagePersistence and a SSFilesystem, so we have data.obj files as backups in case the image saves corrupted.

I'm happy to support getting this up and running as specified above, but I don't want to experiment with mixing the /ss code with the sscom-dtl code. I'd rather see the sscom-dtl code integrated into the /ss code, and the community coalesce on a single bespoke server codebase suitable for both instances.

Regards,

Chris