Date: Mon, 9 Jan 2006 12:36:02 -0500 From: Martin Cracauer <cracauer@cons.org> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no> Cc: Martin Cracauer <cracauer@cons.org>, freebsd-current@freebsd.org, Colin Percival <cperciva@freebsd.org> Subject: Re: fetch extension - use local filename from content-dispositionheader (new diff) Message-ID: <20060109123602.A19382@cons.org> In-Reply-To: <86ace5mibg.fsf@xps.des.no>; from des@des.no on Mon, Jan 09, 2006 at 06:17:55PM %2B0100 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smørgrav wrote on Mon, Jan 09, 2006 at 06:17:55PM +0100: > Martin Cracauer <cracauer@cons.org> writes: > > To make people a little happier, I changed the meaning of the -O > > flag. > > > > Previously giving this non-argument -O flag would use the > > Content-Disposition header after a basic safey check. > > > > Now this flag takes an expected filename as an argument. If the > > argument is given, the server-supplied name will only be used if it > > matches the expected filename. If it doesn't the transport is aborted > > after reading the header. > > All my objections (including those related to breaking the ABI and the > -r option) still stand. I really like your discussion style. Omitting technical details and making nebulous statements triggering what you consider fear factors in the audience. I don't "break" the -r option. It just happens not to work in combination with the -O option. If you had read my diff you would see that I forbid both -m and -r in combination with -O and document this in the manpage. %% As for the ABI incompatibility (now that you at least admit it's the ABI and not the API as you previously claimed), the only reason why it is an incompatible change when the library is newer than the application (it's fine the other way round) is that *you* chose an interface design that locks libfetch against supporting any kind of future HTTP headers or extensions without ABI change. I don't think the FreeBSD operating system can accept getting locked down this way. 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. Personally I wouldn't bother since all two clients using libfetch (fetch and sysinstall) are part of the base system, so lets just bump the shared library version number and get it over with. If you can point me to other software using libfetch I would be happy to design said non-locked interface. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060109123602.A19382>