On Wed, 8 Oct 2008, Daniel Egger wrote:

> The only features though we will ever use are:
> - HTTP 1.0/1.1
> - FTP
> - FILE

> synchronous downloads with range/continuation possibilities. I will continue
> to strive to get those features in the smallest possible package because I'm
> just not interested in the rest.

As I've already explained, I'm also interested in supporting that.

> Unfortunately those features were already present since 7.17.3 so indeed
> there are no benefits in the library but lots of object size bloat. The only
> thing I get by upgrading are security fixes

That's simply not true. There are also a large range of bug fixes for various
aspects of those mentioned protocols.

> If curl wants to suite as many needs as possible one of the main goals
> should be to keep it as small as possible and as modular as possible.

I don't want it to fit "as many needs as possible". I want it to do file
transfers and just about anything that is related to that and the protocols it
supports. Each new thing is considered when people bring them.

I also consider options to make it "as possible and as modular as possible" as
you know by now.

In the end I know that I am the guy who is going to be around in five years
and then I want to be able to still have maintainable code and I want people
to be able to write patches rather easy over time without hitting unnecessary
hurdles. So I try to set some requirements of what I want to go into the code.
You're free to argue for your case and explain to me how my reasoning is wrong
and possibly I could reconsider, but saying that all we do is "bloat" is not
the smoothest way forward to do that.

You whining about your spent time (that seems to have been paid by a company)
is also mostly amusing since I've spent 10 years (of spare time) on this
project.

> I for one could even imagine splitting the library in half for easy/multi
> interface because the multi interface is far to generic/powerful to be of
> any use for many users.

I think such a split could be useful, but also a bit in the reverse direction
of what I'm considering. I'm more in favour of making _everything_ internally
be the multi interface, adn then have the easy interface as a wrapper on top
of that. It will simplify the code with only having one actual way of
functioning internally.

Of course we're not near this situation and I'm not in a situation in my life
atm where I can push development on this either way.

-- 
  / daniel.haxx.se