Hi Marcel and Tobias,

>> " I also discovered I can't apply patches live
>> and save the image, because that means its saved with the RFB server
>> running."
>>
>> That's not good. All patches should be stored in the respective repository and updating the running image, including save, must work. Otherwise some strangely patched monster will grow up and it will be very hard to setup SqueakSource freshly again.

Heh, that won't happen, that was the very thing I set out to fix about
our existing server.  :-)  The use-case I'm referring to above is for
when a temporary patch to the production system (like fixing a typo)
so that the system can be up and running again ASAP until the patch
can be reintegrated into the base code and rebuilt.

I do think the idea about sending the running image a particular kill
signal to invoke a "update yourself from code repositories" is
interesting, however, I think it should only be a temporary patch
file, not the repositories, since that bypasses the normal code ->
test -> build -> deploy cycle.  It could be confusing and dangerous to
have two ways to "update production" and what if you accidently pulled
in more code than just the "one-line patch" but stuff that was not
ready for production..

> Strange, the last time I used the RFB code, It would always ask me whether to shut down the RFB before saving
> just to avoid that.

Please try to think "less-intrusive" about UI design and more along
the lines that we should let the user *tell the computer* what they
want, and never that the computer should poke the user with
unnecessary questions.

Smalltalk users grok the idea that their image state resumes from
where it was last saved.  When I want to start the RFB server, I start
it.  When I want to stop it, I do that.  Saving the image in-between
is completely independent and has nothing to do with it.

> Also, Why is it bad that the RFB remains running? Isn't that the point?

For my personal servers and now source.squeak.org, I want to have the
use-case ability to "press a button to generate a deployable zip file
of everything this system needs."  This includes the VM, image,
scripts, and any resources.  The image is just plain with the needed
code pacakges loaded, I don't want to depend on any in-image state
like running servers or configuration options.

Instead, the scripts reveal the explicit code being used to start up
the various servers, etc.  By not depending on image state, I get to
know exactly what I'm running in production, and this gives me ability
to test and debug elsewhere if necessary.