From owner-cvs-lib  Fri May  8 02:48:01 1998
Return-Path: <owner-cvs-lib>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id CAA22985
          for cvs-lib-outgoing; Fri, 8 May 1998 02:48:01 -0700 (PDT)
          (envelope-from owner-cvs-lib)
Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA22949;
          Fri, 8 May 1998 02:47:50 -0700 (PDT)
          (envelope-from dag-erli@ifi.uio.no)
Received: from skejdbrimir.ifi.uio.no (skejdbrimir.ifi.uio.no [129.240.65.2])
	by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with SMTP id LAA05559;
	Fri, 8 May 1998 11:47:46 +0200 (MET DST)
Received: from localhost (dag-erli@localhost) by skejdbrimir.ifi.uio.no ; Fri, 8 May 1998 09:47:46 GMT
Mime-Version: 1.0
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Cc: Julian Elischer <julian@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG,
        cvs-all@FreeBSD.ORG, cvs-lib@FreeBSD.ORG
Subject: Re: cvs commit: src/lib/libftpio ftpio.c
References: <7854.894562088@time.cdrom.com>
Organization: Gutteklubben Terrasse / KRST / PUMS / YASMW
X-url: http://www.stud.ifi.uio.no/~dag-erli/
X-Stop-Spam: http://www.cauce.org
From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= )
Date: 08 May 1998 11:47:42 +0200
In-Reply-To: "Jordan K. Hubbard"'s message of "Thu, 07 May 1998 10:28:08 -0700"
Message-ID: <xzpogx9w0u9.fsf@skejdbrimir.ifi.uio.no>
Lines: 33
X-Mailer: Gnus v5.5/Emacs 19.34
Sender: owner-cvs-lib@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

"Jordan K. Hubbard" <jkh@time.cdrom.com> writes:
> > Does that mean renaming all functions as well? What will happen to
> > software which currently uses libftpio? It will at the very least be
> > necessary to change the Makefiles (-lfetch instead of -lftpio)...
> Like I said, I'd handle the other 2 major consumers of libftpio if
> somebody wanted to do libftpio and fetch.  It will be a bit of a pain
> from the apps programmer's perspective, but better to do it now before
> too many apps are using it.

OK, I took a quick look at it last night. My approach so far is to
write a new library (libfetch) and integrate the code from fetch and
libftpio into it. The libfetch interface consists of two functions:

FILE *fetchGetURL(char *URL, int flags);
FILE *fetchPutURL(char *URL, int flags);

which work as you'd expect. The flags parameter is used to specify
options such as passive mode, text/binary mode, verbosity, possibly
also protocol version (HTTP 1.0 / HTTP 1.1).

With this approach you gain generality at the expense of efficiency,
since you lose the single-connection-multiple-fetch functionality of
ftpio. To avoid this, I could allow direct access to the various
handlers and provide fetchGetURL() and fetchPutURL() simply as
convenient front-ends rather than as recommended entry point. Should
keeping the single-connection-multiple-fetch functionality be a big
priority?

Right now I'm reading a truckload of RFCs to make sure I don't make
any big blunders :)

-- 
Noone else has a .sig like this one.