"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.