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

[Martin Cracauer]

Dag-Erling Smørgrav wrote on Mon, Jan 09, 2006 at 06:17:55PM +0100: 
> Martin Cracauer <cracauer at 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 at cons.org>   http://www.cons.org/cracauer/
FreeBSD - where you want to go, today.      http://www.freebsd.org/