[getdns-api] Priming the cache
Murray S. Kucherawy
superuser at gmail.com
Wed Mar 13 09:30:08 MST 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>
>> > 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,
> 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...
More information about the getdns-api