guile-user
[Top][All Lists]
Advanced

[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-----



reply via email to

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