From ...
From: Erik Naggum <erik@naggum.no>
Subject: Re: Lisp-based protocols [was Re: OS wars and Lisp]
Date: 1998/12/17
Message-ID: <3122924085350322@naggum.no>#1/1
X-Deja-AN: 423411625
References: <3674be68.951024711@news.newsguy.com> <uogp5xuvl.fsf@res.raytheon.com> <36792849.9175113@news.newsguy.com> <3122775809735246@naggum.no> <367b3b45.115745@news.mclink.it>
mail-copies-to: never
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Newsgroups: comp.lang.lisp

* amoroso@mclink.it (Paolo Amoroso)
| If I get things right, you designed a--network?--protocol whose commands
| can be parsed with READ.

  yes.  for two reasons: Common Lisp already has a well-defined syntax for
  all the object types we need, and the syntax we use is fairly trivial to
  generate and parse for non-Lisp programs, too.

| What are the possible strategies for executing or serving incoming
| commands/requests with such a protocol?

  two points: I don't call READ on the stream itself.  I implemented a
  stream with memory, so I set the stream's mark, eat characters until I
  see a newline, call READ-FROM-STRING on the STREAM-SUBSTRING, and if it
  barfs on end of file, I set up a timeout and eat characters until the
  next newline comes along.  the timeout is cancelled and the mark is reset
  when READ-FROM-STRING succeeds.  the timeout action is simply to emit an
  error message and reset the mark, effectively cancelling the input.
  (this simple setup makes it possible to handle all the clients' input
  streams in one Lisp process, dramatically reducing scheduler overhead.)

| I can think of at least the following:
| 
| 1) direct evaluation with EVAL
| 2) interpretation
| 
| Option 1) has potential security problems, but this may not be an issue for
| systems running in a trusted environment.

  the list of functions that may be called is a property of the stream, and
  if the first element of a list passes this test, the arguments are
  checked to be symbols (which have values) or treated as constants, and
  then I do (apply #'funcall <list>).  running with full safety in the
  functions that accept these arguments, errors are reported back to the
  client with a list (ERROR "<error message>").  the functions basically
  hand off the request to a running process or start up a new process if
  they cannot return immediately with a value.

  this has saved me a _lot_ of work that would otherwise have been spent on
  protocol syntax design and such silly details.  people seem to have
  bought it, and I'm quite happy.  (now, the annoying thing is that TCP
  connections are such unruly beasts -- back to work.)

#:Erik
-- 
  Attention, Republican members of the House Judiciary Committee!  We have
  intercepted a coded transmission from Bill Clinton to Saddam Hussein that
  puts your life in jeopardy.  Clinton is prepared to cease fire if all of
  you are killed by Iraqi terrorists, whom he won't prosecute.  Be warned!