Subject: Re: improving ABI "survival rate"

Re: improving ABI "survival rate"

From: Yang Tse <yangsita_at_gmail.com>
Date: Fri, 28 Nov 2008 14:07:12 +0100

2008/11/28, Daniel Stenberg wrote:

> Yeah, the save and use options things are really not very fun to get working
> nicely...

Yep, they're part of the problem.

> > We have duplicated all the external functions which had an ares_options
> struct argument, and also introduced ares_setopt(). Not to mention the
> increased complexity that the library internals will suffer.
> >
>
> I sense a negative attitude to this idea here...

Not a negative view on the general concept of being able to keep ABI
compatibility and introduce 'something' new that also allows to use
the new features. And of course not a negative attitude towards
anyone.

But... Certainly a bit annoyed by my approach to how the above could
be achieved. I'm not even sure that it could certainly be done, and
some unforeseen surprise might await us ahead.

> What approach do you think is the better way forward then?

Man, I really wish I had an answer to this question.

Maybe some new idea would pop out, if as a starting point we supposed
that the actual ares_options and associated functions did not exist at
all and wanted to provide the capability of initializing channel
options from user data or from another channel which has magically
been setup. And later on in the mental design make the existing
ares_options internally use the brand new functions.

> I want us to figure out a way to migrate the API to something that will
> survive easier. I'm not saying my suggestions are the only solutions nor
> that they are perfect in any way, but I'm not seeing a lot of other
> alternatives being suggested.

Hey, don't take my comments as plain criticism, take them just as a
bar chatter with a friend designing software on a paper napkin. I have
tried to figure out how it would be done, and probably the problem is
on my mental implementation of an otherwise perfectly valid concept of
keeping ABI compatibility while providing a future escape route.

And yes, I also wish others would be sharing ideas, even the strangest
ones, totally or in part can be the origin of something useful.

> First I think we should make it possible to set all options using the new
> way (which might take a while depending on the size of the developer hoard
> that will take onthis task :-) ),

Hey, if no one has noticed, the above is a call for help. Things don't
happen magically. Work is the force that changes things.;-) After all,
its 'the community' which wants a feature called ABI compatibility.
:-)))))))))

-- 
-=[Yang]=-
Received on 2008-11-28