Re: [Help-smalltalk] gst-remote architecture

[Stefan Schmiedl]

On Fri, 19 Jun 2009 15:04:20 +0200
Paolo Bonzini <address@hidden> wrote:

> Stefan Schmiedl wrote:
> > Why do we need a dedicated gst-remote binary?
> 
> No, we don't.  The body of gst-remote is installed in 
> /usr/share/smalltalk/scripts/Remote.st and it is, in some sense, the 
> moral equivalent of the drb server and library.  It would be possible 
> and easy to move the gst-remote client to a package so that other 
> scripts could act as gst-remote clients.

It would be _very_ convenient to be able to do this.

Since we're currently all so hot about web app servers, I'd
really like to be able to remotely "save" the image (for
backup or debugging) or put the server into "maintenance mode"
for extensive data massage sessions that should not be interrupted
by users. Basically, it's stuff used rarely where I don't
want to provide or need a real GUI for.

> Note however that drb is not a REPL.  It is more than a REPL in that
> it provides distributed objects.  But if I understand correctly it is
> also less than a REPL in that you would need anyway to write the
> logic to read evals on the client (from the command line) and a
> server object to capture stdout and send it back to the client.

My typical use cases would be:
- "execute" a message on the server, where I don't care
  for the result of the evaluation
- "query" the server, where the result is important.
In the query case, it's (of course) my responsibility to
answer something that the client can handle, i.e. "primitive"
objects, or loading necessary definitions into the client
image first.

> I had written a long blurb on gst-remote before writing the above 
> answer.  It didn't really answer your question but I think it is 
> interesting anyway, so here it is.

Much appreciated. In fact, it should go into the wiki.

Thanks,
s.