SilkMachine project

[Kelly Murray]

> Just to name an example, it still leaves you with the pipe model
> of interprocess communication: everything is a stream of bytes.
> Ripping out pipes and replacing them with some more sophisticated
> object-passing system isn't going to be so easy.

But it's easy, and that's the point!  
Silk programs communicate by sharing persistent objects.
You can "fake" this today, by having all programs run in the same address space
and share transient objects.

> have Unix signals, whereas a more fundamentally derived Lisp
> system might want to implement asynchronous traps with
> exceptions.

CL already has a condition system, which is a higher-level view of
signals, and is already supported by ACL today.

> But don't argue -- go thou and do it!  Prove that I'm wrong: show
> me it can be done.  We need hacking as well as discursion.

OK!  let us walk-the-walk and not just talk-the-talk!
Get a copy of ACL for Linux and check out CLOS, conditions, and
dumplisp.  After you've played with this for a day,
let me know if it showed you it can be done.
If not, I'll spend more time to produce example programs.


> > As someone mentioned, it is difficult to get started writing code
> > with a persistent object system when you don't have one.
> > However, ACL has a "dumplisp" capability that saves the state of
> > an entire Lisp process.  So transient CLOS objects can be saved this way.
>
> Neat!  Can Franz contribute Allegro source to help make this happen?

As I've said, how much I myself as well as Franz can help and
participate depends entirely on what we are doing and where we are
going.  I have been thinking about these things for *years* ---
I very clear ideas and direction on what I want to do.

As I've stated, my goal is to "provide a platform for lisp programmers to 
succeed in the marketplace."
That does NOT mean a project that is simply intellectually
challenging, interesting research, "cool",
or will just impress our friends and collegues.
It means doing something that can create real value in the marketplace.
I've been trying to describe a way forward in which the latter is not
in conflict with the former.  In other words, something exciting and
interesting that can also be valuable.
This value is also more than just software, it is also
having the developers who can use it.  

I think this has to involve using ACL in some form.

ACL has already been ported to run under Linux.
Franz has already developed AllegroStore which implements
a persistent object system, which I've worked on extensively.
I've already written a working web server (written in SilkScript)
that uses persistent objects,
and have developed a few simple applications, 100% web-browser user-interface.
I've already started working on a hardware page-level persistent object
system, which is working in the prototype stage.
I've already written a very fast simplified CLOS subset.

So I believe we're really quite far along towards my goals.
If we can continue to build upon the work I've done rather than
reimplement all this and other existing things,
I think we can make significant progress in a short time
if the efforts are put towards the right things.

The most significant work at the Language level is

  o defining/building a module/library system that is totally object-based,
    not source-code-file based.  For example, the package system should
    be completely re-thought.  The export,import at the symbol level
    is inappropriate.

  o determine exactly what Silk and SilkScript includes/excludes
    from Common Lisp.

  o Maybe define a simple lisp kernel layer, in which Silk can use


There is effort needed for the development environment.

 o Source Code Stepper
 o Debugger
 o Editor
 o Inspector
 o "Interface Builder"

There is much work at the "system application" level that needs to be
done. I mention a few things, some are trivial, some are time
consuming, none of which will be particular difficult to write.

 o Unix "cron", such that code is run at specified intervals

 o Replace sendmail.  Write SMTP, POP support
   and implement the web-browser user interface for MH-like capability. 

 o A FAX system that allows documents to be received and sent

The web server itself can use some work:

 o  There is a whole lot of statistics and
    tracking stuff that needs to be written for analyzing hits and
    click-trails, etc, and displaying the results on a web-browser (wb)
    This is really easy to do.  All the "hits" are just objects,
    it just a matter of "doing the math" and displaying the results.

 o  ECommerce - Check out http://www.viaweb.com for a *very impressive*
    all-web-browser-based interface to building and using web-storefronts,
    (this website is actually almost totallywritten in clisp!)
    We need something like that that can be used for buying/selling
    over the web


Actually, Rainer Joswig has made plenty of suggestions for
improvements/utilities for CL-HTTP, many of which are also applicable
for including in SilkServer.
I've been loath to publically criticize CL-HTTP, since John Mallery has
obviously put a tremendous amount of effort into it, but...

> [CL-HTTP] tries to actually handle HTTP. It does support all
> the HTTP stuff and more. HTTP *is* complicated.

This is one of the problems!
CL-HTTP has taken even the worst of HTTP and then added its own
"abstraction" layers on top!  It is MORE complicated to create
and maintain a website than it ever was before.
CL-HTTP will not attract anyone to use Lisp.  It will only be used
by existing Lisp programmers, and even they have a lot of problems
trying to use it.

SilkServer has taken a very different approach.
It makes everything simpler by only *using* HTTP
to provide higher-level and simpler functionality.  


-kelly

P.S.  Perhaps I should ask people to send me mail directly if
they would like to help me work on my SilkMachine project.
I'll be meeting with Franz Inc. management very soon, and I'll
need to have some idea of how much outside development support
I can rely on for getting this project implemented.