mikemac's proposal

[Mike McDonald]

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

  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
      - 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/)
    b) command line interface
      - use the CLIM command tables to implement a lisp listener that
	works on ascii streams, aka the console, serial lines, ...
      - implement a history/editing system to support the lisp
	listener.
    c) user apps
      - editor. initially, use whatever editor suits you. Long term,
	implement an emacs style editor. We can either emulate elisp
	inorder to "borrow" the [X]emacs code base or we could start
	with hemlock (CMUCL's emacs editor), or build our own from
	scratch. (I'd guess it turns out to be a combination of 1 and
	3.)
      - debugger. we need both an "inline" debugger and a window
	based debugger. The inline one is what you'd normally fall
	into when encountering an error (standard lisp debugger). The 
	window based one for more "intense" debugging. Maybe integrate
	it with an "inspector". (With CLIM, inspectors are alot less
	useful! Every printed representation of an object on the
	screen is mouse sensitive, with one of the default actions
	being describe this object. Of course, everything describe
	prints out is mouse sensitive too. Walla, you can navigate
	thru any object you want!)
      - 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! :-)
      - misc. utilities. tar, gzip, ...

  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

  At this point, I think we'd have one neat machine. You'll notice
that I haven't said anything about Linux/Flux/BSD, file systems,
schedulers, ... that you'd expect from an OS. Nor what common lisp
to use! That comes all comes afterwards. All of this stuff should be
able to be implemented on just about any ole common lisp.

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

  OK, I have my asbestos undies on. Flame away!!

  Mike McDonald
  mikemac@engr.sgi.com