Shawn Rutledge scripsit: > A client REPL opens an SSH connection to a server and starts a server > REPL. Each of them evaluates what the other sends. So if the server > sends > (let ([v (make-thing)]) > ...) > and the client evaluates it, then later the server wants to ask the > client to do any operation on the previously-created v, how can the > client now access the variable v, which exists only in that > environment created by "let"? Just binding it to a top-level name > would pollute the namespace. Having to bind the accessor is not so > bad, because the same accessor can be used to modify multiple remote > objects.
The only safe approach is for each side to maintain a notion of "the other guy's global environment" which can be read out of using (get-environ 'x) and set with (set-environ! 'x value), and transmitting all code in terms of that. Note, however, that any scheme involving evaluation of whatever the other end sends involves inordinate trust. Unless the server and client can be certain of each others' identities, it's better to write your own sandboxing interpreter, something Scheme makes very easy. -- We are lost, lost. No name, no business, no Precious, nothing. Only empty. Only hungry: yes, we are hungry. A few little fishes, nassty bony little fishes, for a poor creature, and they say death. So wise they are; so just, so very just. --Gollum [EMAIL PROTECTED] http://ccil.org/~cowan _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users