Re: proposed API breaks with async DNS

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Wed, 4 Nov 2009 23:20:03 -0800 (PST)

On Tue, 3 Nov 2009, Daniel Black wrote:
>> I'm not sure I see the connection between earlier parsing and the necessity
>> for linked lists.
>
> the total number of DKIM signatures isn't known in the dkim_header() function.

True, but that doesn't make a linked list a better data structure here.
Both require creating a new handle and then updating the existing set to
include the new one which is simple in both cases. If you use some growth
prediction, you can avoid having to call realloc() often in the case of
the array, in which case adding a new node is actually slightly easier on
average.

I don't have a problem with lists, but there's not yet a compelling
argument to move away from the current method.

> Speaking of public data structures, we have some variables not visible
> in the API that are in the shared library generating potential linker
> conflicts (nm nm -g --defined-only ./libopendkim/.libs/libopendkim.so |
> fgrep -v dkim_
>
> libopendkim_la_LDFLAGS = -export-symbols-regex '^dkim_.*'

Hmm, that sounds scary. I'll take a look.

> library-izing may add to latency as the application would need to do the
> lookup synchronously and/or handle its own author domain and signature
> domain logic (that I've hopefully done already in dkim_header)

Library-izing itself won't add any latency that isn't already there. It's
a matter of whether or not the feature is turned on.
Received on Thu Nov 05 2009 - 07:20:19 PST