[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (net http) 0.1
From: |
Evan Prodromou |
Subject: |
Re: (net http) 0.1 |
Date: |
26 Mar 2001 21:21:01 -0800 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "MG" == Martin Grabmueller <address@hidden> writes:
Me> Your comments appreciated.
MG> Have you already looked at the guile-www CVS module? It
MG> provides similar functionality, but it is old and I don't know
MG> if it is still maintained. It does not use GOOPS, but maybe
MG> you can get some interesting information from it.
OK, that's very helpful, I'll check it out. I use the Debian guile-1.4
package, so I'm probably a little behind on the latest stuff. The main
reason I started writing (net http) was because I read this:
"HTTP routines
It would be cool if people could use Guile to implement web
robots and the like. Tim Pierce started to work on this, but
it's not finished."
on this page:
http://www.gnu.org/software/guile/ideas.html
...and then I searched around a while looking for +HTTP +Guile, and
couldn't find anything except for plaintive requests on various
mailing lists, so then I figured it'd be a good exercise, and I needed
it, so I wrote it.
MG> 1. To make it work with CVS guile, you should add the
MG> following to the beginning of http.scm.
MG> [...]
Oh. OK.
MG> 2. The documentation for the objects int README is a bit
MG> confusing:
MG> The description for the `content' slot is the same for
MG> request and response objects, and it was not clear to me how
MG> they are used.
Whoops! Well, you know what they say: "Copy-and-paste, always a
waste."
Yeah, the "content" slot is the content of the message. For a request,
it's either the POST parameter, or some PUT data, or stuff like
that. For a response, it's the file you requested, or the results of
your query, or whatever. "content" is the meat of the message.
I decided to use ports here because I figured it was just toooooo
wasteful to store everything as a string within the message
object. So, you have to set up a port that the library can read from
when sending a message, and it will give you a port to read from when
retrieving a message.
It is probably a good idea to instead allow small messages to have
string content, and larger messages have ports, and use a check
(string? port?) when sending.
MG> Thanks for posting interesting code
Hmmm... "interesting" code. I'll take that as a compliment. B-)
MG> (maybe I should learn GOOPS, too)!
You -should-! GOOPS roxx like soxx in a boxx. I really like CLOS, and
GOOPS is very faithful to the model. It's a pleasure to write code
for.
~ESP
- --
Evan Prodromou
address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
iD8DBQE6wCM6ozwefHAKBVERAttCAKDVLthbzgZFNroFF5Rzg//56GfAfQCgjcRE
zPBfzu4+xWbzkBe1cEqPpO0=
=Z4h4
-----END PGP SIGNATURE-----