Date: Mon, 09 Jan 2006 22:57:54 +0100 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) To: Martin Cracauer <cracauer@cons.org> Cc: freebsd-current@freebsd.org, Colin Percival <cperciva@freebsd.org> Subject: Re: fetch extension - use local filename from content-dispositionheader (new diff) Message-ID: <86u0cdvzbx.fsf@xps.des.no> In-Reply-To: <20060109123602.A19382@cons.org> (Martin Cracauer's message of "Mon, 9 Jan 2006 12:36:02 -0500") References: <20051229221459.A17102@cons.org> <868xu22mmp.fsf@xps.des.no> <200512301856.28800.jhb@freebsd.org> <200512310115.40490.jhb@freebsd.org> <20051231015102.A51804@cons.org> <43B66EF1.4020906@freebsd.org> <20060109113634.A17206@cons.org> <86ace5mibg.fsf@xps.des.no> <20060109123602.A19382@cons.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Martin Cracauer <cracauer@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 --=20 Dag-Erling Sm=F8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86u0cdvzbx.fsf>