Re: Simultaneous Guile users

[Mikael Djurfeldt <mdj@nada.kth.se>]

I'm sorry that I've waited one month before answering your letter.
The reason is that Guile couldn't do what you were asking for in a
simple way until very recently.

See the recent posting "Guile server" on this list for example code
which sets up a server supplying multiple repl sessions to clients
connecting via telnet.  You could use that code as a start.

However, there is still a problem:

You'll have to use the module system.  Guile's present module system
will be replaced.  Therefore, people have not cared much for
documenting it.  On the other hand, it seems that it'll take a while
before we'll have the new one.  I'll see if we can put a few words
about the old one in the reference manual.  In the meanwhile, use
"boot-9.scm" as documentation.  :)

But, I think your idea is great, and certainly achievable with the
current Guile.

Eric Buddington <eric@sparrow.vgernet.net> writes:

> 1) Since guile doesn't like to be multi-threaded, it looks like all
> scheme input will be processed in the same thread.

You probably want to be able to serve multiple clients simultaneously.
A natural way to do this is to spawn a new thread for each new
incoming connection.

> Is there an obvious way to keep different users in different
> namespaces,

You can create a separate module for each user.

> and to allow access to different functions from different callers?

Yes, by controlling what bindings the user's module inherits from the
start.

> 2) I've seen some system call interfaces, for filesystem access,
> system info, etc. Some of these could easily be security holes. Is
> there a way to disable these? I imagine my purposes would require only
> math functions and ones defined in my code.

I suggest that you create a module M from scratch.  Populate this
module with the required bindings.  For each incoming connection,
create a new module which has M's interface on the use list.

Note that both M and the module created when spawning a thread can't
be ordinary "scm" modules (which copy bindings from the root module)
but must be "vanilla" modules.

Best regards,
/mdj