On Tue, 22 Mar 2011, Dima Tisnek wrote:
> It seems there are two classes of c-ares users, those who initialize it by
> calling ares_init, never set any options and use c-ares as a simple
> asynchronous resolver, and those who call ares_init_options, set loads of
> options (and often set servers explicitely) and thus use c-ares as a toolbox
> for various name resolution problems.
>
> So in a way, c-ares serves two distinct purposes. Is it so, or am I missing
> something?
I think you're right and that the majority of users is in one of these camps.
> Currently ares_init(ch) and ares_init_options(ch, NULL, 0) mean the
> same, and it appears to be a good convention.
> This gets tricky if we are to include automatic reinitialization for
> simple users without quietly introducing a change to toolbox users.
Yes, and I think it is a reason as good as any to not introduce this feature
by default.
> One way is to break init/init_options equality and include reinit option
> (and possibly some default timeout) into ares_init call and document that in
> the man page.
Right. It will also make apps not suddently start working differently when
they upgrade to the future c-ares version with reinit-capabilities.
> Another option is to split c-ares into two separate entities, say
> c-ares-simple and c-ares-toolbox, projects like libcurl and iftop would use
> simple and projects like lwip and xymon use the toolbox.
I wouldn't like that and I fail to see how that would benefit us very much now
or in the future.
-- / daniel.haxx.seReceived on 2011-03-22