On 08.10.2008, at 00:20, Daniel Stenberg wrote:

> No. The libcurl API is set and fixed and we don't offer any
> alternative APIs. I'm all for providing configure tweaks to modify
> internal things but I want the line to be drawn below the API. If
> you want to disable things, you make the API remain but always
> return error.

Oh well, that's not a patch I will provide. I only want the "easy" API
and have
no use at all for the "multi" API so I'm not willing to pay the price
even for
some stubs because that's still waste and it's also an additional
burden for
the applications trying to use the API because they have to take care
of the
potential runtime implications. Every problem I can catch at compile
time is
preferable to any I can only catch at run time!

> Your patch as suggested introduce a whole slew of "ifdef maze" so
> its funny you say you dislike that!

I don't necessarily need to like code I think is necessary.

> For example you could easily #define macros for functions that are
> no longer present in the code like:

> #define func(x,y)

> instead of:

> #ifdef HAVE_DISABLE_MOO
> func(a, b);
> #endif

> I like that since it enhances readability a lot and makes it less
> error-prone when people come moving around functions etc in the
> future.

I have no idea how that is supposed to work the way I intended it too.

> All this taken into account, I'm far from convinced this is a patch
> we should apply.

I would have appreciated the application of this so I don't have to
maintain it in
our local trees alone but if it doesn't make sense for you then it is
better not
to apply it to the official distribution.

The spirit of this patch will still live on and basically is to reduce
the featureset
by the multi API (which is almost completely superflous for embedded
applications) to
make it more suitable for exactly those cases.

Right now the library is becomming fatter with every release without
providing
any benefits except for security fixes which is a trend I not only
like but need to
counter or I'll have to resort to older versions to meet size
constraints.

Servus,
       Daniel
Received on 2008-10-08