Re: fetch extension - use local filename from content-dispositionheader (new diff)

Martin Cracauer <cracauer_at_cons.org> writes:
> I really like your discussion style.  Omitting technical details and
> making nebulous statements triggering what you consider fear factors
> in the audience.

I could comment in like manner on *your* discussion style, which
consists of ignoring my objections and arguments and then accusing me
of not making any; of trying to pretend that I don't exist and / or
don't matter; and of blaming me for requirements which were laid down
for libfetch by others before I started working on it.

> I don't "break" the -r option.

Yes, you do.  You moved the fetchXGet() call so it occurs before its
arguments are fully initialized.

> Now, for technical solutions, I previously offered you to redesign the
> interface so that it would be extensible in ABI and API compatible
> manners - which you did not reply to.

I submit that there is no way you can do that.

libfetch started out with a very tight and clean API based on its
primary "mission statement" which I explained in a previous message.
For a number of reasons (mostly to do with supporting existing
features of the old fetch and helping bsd.ports.mk deal with broken
distfile servers), it was necessary to extend that API somewhat in
ways which I wish could have been avoided: the fetchX*() calls (which
aren't too bad) and a handful of global variables (which *are* bad,
not to mention undocumented).

What you propose is to follow that unfortunate precedent and add even
more badly designed interfaces and complexity to support features
which do not further the goal for which libfetch was created.

More badly designed interfaces will not turn libfetch into what you
want it to be.  It will only make matters worse.

You also seem to fail (or refuse) to understand that libfetch is
already quite complex and fragile; that complexity in software rises
exponentially, not linearly, with the number of features; that this
rule has already been demonstrated several times, both by myself and
by others who were certain that they understood better than me how
libfetch should work; and that if something breaks as a consequence of
your obstinacy, I'm the one who will have to pick up the pieces.

If you want a library that fully implements RFC 2616 and allows you to
manipulate and access the full range of HTTP headers, take a look at
libcurl; and if you just want a quick and dirty way to download an
attachment from Bugzilla and save it under its proper name, use Perl
with Net::HTTP; but please leave libfetch alone.

(to stave off markm's biting sarcasm re Perl: it really *is* quite
trivial, and there is a nearly complete example in the first few lines
of the Net::HTTP man page)

DES
-- 
Dag-Erling Smørgrav - des_at_des.no