Skip site navigation (1)Skip section navigation (2)
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>