[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: [Axiom-developer] Simple web server code for GCLfor Wind

From: Camm Maguire
Subject: [Gcl-devel] Re: [Axiom-developer] Simple web server code for GCLfor Windows
Date: 04 May 2005 10:11:47 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


"Page, Bill" <address@hidden> writes:

> Camm,
> You are right. The simple GCL web server program that you
> wrote is working on both linux and Windows. Great!

Wonderful.  Thanks!

> On Tuesday, May 03, 2005 9:56 AM Camm Maguire wrote:
> >...
> > What this will send to the gcl function 'foo' is 'get /dir'
> > #'foo must find a file or directory by that name to produce
> > output, which I'm guessing does not exist on your system.
> > You can add a diagnostic like: 
> (defun foo (s) 
>   (let* ((get (read s nil 'eof)) 
>          (fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
>          (fn (when (probe-file fn) fn)))
>     (format s "HTTP/1.1 ~S~%" (if fn 404 500))
>     (format s "Content-type: text/html~%~%")
>     (format t "get ~a fn ~a~%" get fn)
>     (when fn
>       (if (pathname-name (pathname fn))
>           (with-open-file (q fn) (si::copy-stream q s))
>         (dolist (l (directory fn)) (format s "~a~%" (namestring l)))))
>     (close s))
> )
> > You can also do 'telnet localhost 8085' and type 'get /dir'
> > to see the output, which I think is likely '404' in my pseudo
> > html error code example. 
> Thanks. This works exactly as you claim. For example on my system
>   http://localhost:8085/msys/1.0/home/bpage/
> produces a list of files and
>   http://localhost:8085/msys/1.0/home/bpage/repository.html
> displays the web page in a browser (See Content-type above).
> Just to play a little (although I know almost knowing about
> lisp :) I also changed the file list to HTML format like this:
>  (format s "<a href=\"~a\">~a</a> <a href=\"~a/\"> /... </a><br>~%"
>    (namestring l) (namestring l) (namestring l)))

This is exactly the idea.  You can also call other functions from foo,
and compile them.  With both the user invocation model currently in
place on Linux and Windows, and the fork() background model currently
in place on Linux, such changes will have to precede the actual call
to #'bar/#'socket respectively.  (Just to be a bit more clear, on
Linux you should have the option '(si::socket 8085 :server #'foo
:daemon t)' and '(si::socket 8085 :server #'foo :daemon :persist)',
both of which will fork and invoke backgrounded running servers, the
latter example of which will allow the forked server to survive when
the current image is terminated.)  If/when the stdio multiplexing gets
done, then one can modify #'foo while the server is running, changes
to which will be available on the next connection.  This feature seems
less important to us at this juncture.

> It would be nicer to make the result and the content type depend
> on whether something was a directory or on the type of the file
> etc instead of the syntax of the name, but I could not easily
> discover how to do that in GCL. Specifically how can I tell a
> directory from a file? Can anyone suggest a suitable "Getting
> started in GCL" tutorial?

In lisp, the file system is accessed via a 'pathname' abstraction.
Think of this a sa structure with several components, name, directory,
type (e.g. suffix), device, even host and version if I recall.
Directories have nil in the name and type fields.  The sample code
uses this to distinguish between them. 

As for content-type analysis on files, you have the following options
in order of simplicity to performace:

1) Use an external utility via run-process:

(let ((s (si::run-process "file" (list "/etc/passwd")))) (read-line s nil 'eof))

***** Spawning process file 
"/etc/passwd: ASCII text"

2) Open the file and implement the 'magic' used by file in lisp -- see
   /usr/share/misc/magic on Linux, a copy of which is appended below.

As for tutorials, I'd suggest:

1)  Practical Common Lisp:


2)  The Common Lisp Hyperspec:


> Anyway, it seems clear that we could use this approach to develop
> a portable HyperTex browser for Axiom if we decide to go that
> root.

If I can delay the stdin/socket multiplexing, this might be
preferrable at this point.  I need to know if blocking the axiom
process while serving the hyperdoc on Windows is a showstopper.

Take care,

> Regards,
> Bill Page.

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]