[getdns-api] Priming the cache

Murray S. Kucherawy superuser
Wed Mar 13 17:30:08 CET 2013


I think it would be ugly to have N implementations of a standard API with N
(or more) incompatible extensions to add a common capability.


On Wed, Mar 13, 2013 at 11:38 AM, William Chan (???)
<willchan at chromium.org>wrote:

> On Wed, Mar 13, 2013 at 11:11 AM, Paul Hoffman <paul.hoffman at vpnc.org>wrote:
>
>> On Mar 13, 2013, at 11:07 AM, William Chan (???) <willchan at chromium.org>
>> wrote:
>>
>> > I think the feature is reasonable, but I don't understand why it should
>> be part of the API. Can someone explain why this is the best place to put
>> it? Why not keep this implementation specific?
>> >
>> > The reason I ask is, does this require all implementations of this API
>> to implement a cache? That seems like unnecessary burden on
>> implementations, since I can imagine many implementations simply proxying
>> DNS queries to some other service that may implement caching.
>>
>> I was intending of adding the context function to note that not all
>> implementations would have a cache. If you said "prime the cache with X"
>> and the implementation had no cache, the call would return a new error,
>> GETDNS_RETURN_NO_CACHE_TO_PRIME.
>>
>
> So we could do that. If implementing caching is optional, then do we get
> much advantage from standardizing an API to modify the cache? I don't
> really understand what value this return value provides. Presumably this
> error is always returned given a certain implementation. That means that at
> the point that I select my implementation, I need to know how to handle
> this case, not dynamically during application runtime.
>
> I think caching is very implementation specific. How large is the cache?
> What's the eviction policy? What happens when the application tries to
> preload too much into the cache? Etc etc. AFAICT, standardizing such an API
> would either fail to make application developers agnostic of the
> implementation, or standardizing this API would overly constrain
> implementations and perhaps hurt performance.
>
> So yes, we could definitely add this to the standard API. Do people think
> there's much value though? I think it's a nice feature for implementations
> to provide, but I am less convinced that we need to provide a standard API.
> I think it'd be cool if someone explained why this is good to standardize
> in the API. Just my two cents, I don't really care :)
>
>
>> --Paul Hoffman
>
>
>
> _______________________________________________
> getdns-api mailing list
> getdns-api at vpnc.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vpnc.org/pipermail/getdns-api/attachments/20130313/134b0b2e/attachment.html>



More information about the spec mailing list