Subject: [clisp-list] Re: Networking?

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Thu Feb 12 05:31:01 2004

Hi,

John K. Hinsdale wrote:
>in fact if one found
>oneself using the FFI so that he could make TCP/IP related calls from
>"C" for functionality he needed from Lisp, that is probably an
>indication that the socket lib is lacking and thus occasion to
>incorporate instead those functions in the socket lib instead.
>Hope that made sense.

Indeed. A decade ago, I made Emacs on my Amiga work with VM (mail client). I added a vm-pop.el and had feedmail.el talk to SMTP servers by adding a single, reasonably small function.
Nowadays I'm still using feedmail.el to have GNUEmacs on my MS-Windows box send out E-Mail to the SMTP servers in the corporate intranet.

My point is that all it took was to provide the function open-network-stream (cf. tcp.el for a start). Based on that, enough buffer/file/string/process manipulating functions and source code examples were available for sending and reading data.

Most of the needs for socket support discussed in clisp-lisp IMHO require little socket-specific code (not talking about UDP here) -- yet requires some Lisp-level API to use.

Like in Emacs, a lot of benefit can/could be reached by having good streams/socket integration (which I believe is there in newer CLISPs), so that most of the work can be achieved using standard CL operators to talk to a (possibly bidirectional) stream of bytes or characters.

>Now, I *AM* thinking of writing a simple SMTP client for my programs
>to send Email notifications to me for certain events.  For that I
>would use the socket interface directly from Lisp to speak the SMTP
>protocol.
I wouldn't use the socket FFI here and rather consider the Emacs-like approach. I'd rather use Lisp streams to talk to some socket with an SMTP server at the other end. Esp. CLISP has transparent support for :line-terminator and the mandatory CRLF. I believe CLISP's listen/input-available-p support has gotten to the point where it's actually usuable. But other guys in this list actually using the code should comment on that.

A problem IMHO often is that toy code is trivial to write. For example, My Emacs vm-pop.el did not know about time-outs and other network oddities. It entirely relied on mechanisms external to my code to deal with such situations. E.g. me sitting in front of Emacs and hitting ^G when I felt it took too long, because the network connection was poor or whatever.

That is possibly why we often see simple libraries (for any programming language), and rarely really defensive and robust code.
Granted, it's hard to provide such code, because it's hard to factor the environment into code (like my ^G Emacs example hopefully shows).

So there tens to be a lot of look-at-code & modify for own needs, whereas people (esp. Java people) try to standardize try-to-do-and-consider-all-and-everything APIs. I'm unsure whether this is beneficial in the long-run. At least, there seems to be a market (or economic niche?) for small, ad hoc solutions, that mostly work, usually.
[IMHO, Python's libraries are full of this, for better or worse, YMMV]

Regards,
	Jorg Hohle.