mikemac's proposal

Marcus G. Daniels marcus@cathcart.sysc.pdx.edu
30 Apr 1997 00:49:35 -0700


>>>>> "MM" == Mike McDonald <mikemac@titian.engr.sgi.com> writes:

MM>   OK, here's my ideas on how we should proceed:

MM>   Here's a list of capabilites I'd like to see in a PC LispM:

  1) User Interface
    a) Windowing system
      - use the X server for the drawing of bits and interfacing with
	the gazillions of video cards

There is SVGALIB on Linux, although I think X is necessary in any case.

      - implement a version of CLIM. This gives us presentation types
	and a structure for implementing a command loop. Team up with
	the free-clim people inorder to do this. 
	(ref: http://www.cons.org/free-clim/)

How about STklos?  Tk has been ported to everything.  I bet there is more
STk code floating around then there is CLIM.

      - web browser. If we're going to support a fancy lisp based web 
	server, it sure would be nice to be able to test it out from a
	fancy lisp based browser.
      - mail reader. Hey, if you've kept up with the five hundred odd
	messages in this list so far, you don't need convincing!
      - news reader. For when we have spare time from implementing
	this beast! :-)

GNU will be working on an Elisp translator for Guile, and the Emacs
C code will probably end up in a shared library.  Rewrite Gnus?!  Crazy! :-)

      - misc. utilities. tar, gzip, ...

I say just use the C code.

  2) Networking
    a) Generic networking system
	Symbolics had a neat way of describing network protocols into
	two parts, a generic descriptor like file-transfer and then a
	protocol specific tag, like ftp, or nfs. When a user typed in 
	a command like "Show Directory titian:/usr/people/mikemac",
	Genera would lookup the type of host that Titian was (Unix),
	then it would look to see what ways it knew how to do
	file-transfer operations on Unix hosts. It then tried those
	methods in a specific order, specified by the namespace object
	for that host. As a user, this meant that I didn't have to
	worry about how to get the files, that was the job of the
	computer. These are the ones I think we need (maybe more!):
	Oh, these should all be proxy/firewall aware whenever
	possible. 

      - File-Transfer. NFS, ftp, rcp, ..
      - Telnet. Telnet, supdup (anyone use that anymore?), ...
      - Remote-exec. rsh, ...
    b) daemons - lots and lots of them!
      - SMTP (Simple Mail Transfer Protocol aka sendmail)
      - HTTPD (Here you go Kelly!)
      - telnetd
      - ftpd
      - nfsd
      - rshd
      - news

Hmmm..

o ange-ftp and especially `efs' for Emacs do this. 

o A `userfs' module for Linux could be written
  in Lisp to do this fairly easily.  I've used userfs for FTP-based backups
  just using `tar'.. works fine.   tsx-11.mit.edu:/pub/linux/ALPHA/userfs

o GNU Hurd creates a filesystem namespace using `translators'.
  To mount FTP, for example, a command like this is used:

     settrans /mnt /hurd/ftp /pub/Silk ftp.silk.org

New translators could simply be written using CMU CL or whatever
Lisp implementation.  Or perhaps the translators would better be 
stubs that would forward messages to the Mother Ship?

MM> All of this stuff should be
MM> able to be implemented on just about any ole common lisp.

I think only a few of those system services would actually be so
beneficial to be worth rewriting.  And happily CL-HTTP already exists!

MM>  Now we can start doing the nifty stuff like persistant object
MM> stores, networking stacks, OS mods/support, SMP support, .... This is
MM> not meant to imply that if someone really wants to go do some of those
MM> things now, that they can't. This is a volunteer effort afterall. You
MM> can do what you want!

I think these are important components:

1) Integrate with existing free Unix software (GNU, Linux, X11, Tk, etc.)
2) Help implement threads for CMU CL.
3) Implement a checkpointing Lisp filesystem and/or an
   voluntary persistence capability.
4) Create or adapt a portable, free Lisp-programmable web browser
   and/or target the JVM (e.g. Kawa).
5) Find a way to make kernel (e.g. Linux/Mach) scheduling decisions in Lisp.