[bind10-dev] Data source configuration

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/23/2012 10:09 AM, Michal 'vorner' Vaner wrote:
> Hello
> 
> On Wed, May 23, 2012 at 12:22:58AM -0700, JINMEI Tatuya / 神明達哉
> wrote:
>> - In either approach, I'm not sure whether we can reasonably
>> hardcode the matching strategy as part of configuration, because
>> it could be application specific: auth allows partial match, but
>> others generally don't.  Also, in our current API, "partial
>> match" can only happen for findZone(); others only look for an
>> exact match.
> 
> Hmm, good point. So we may want do have two matching lists
> depending not on auth/not-auth but on type of matching. The
> semantics need to be thought about a little bit, yes.
> 
> Would it work if we had two lists, one for partial match one for
> exact match?
> 

I suspect that in nearly all use-cases of 'auth-like' matching with
multiple datasources, you'll want a best-match approach; when you set
it up to stop at a partial match you might have a speed-improvement,
but as an administrator you do need to make damn well sure that you
don't have any superzones in datasources earlier in the list. So from
an 'i'm and administrator and i don't want to shoot myself in the
foot' that's really the only sane value ;)

Of course other matching algorithms than best-match could certainly
give you a configurable speed advantage here, especially if you set it
up so serve all zones from memory but stored in database; but in that
case I don't know if we need to mention the db one in the match list
at all (as mentioned on the wiki page as a reason to split them up).
But also if you are very sure you don't have child zones in later
datasources.

Would a per-datasource-list be needed or would one global algorithm
setting (per type of lookup, if necessary) be enough?

For types that want an exact match always, well, there isn't much to
configure, is there? At this time i do not see anything other than
exact first match being useful.

That reminds me, didn't we always have a partial match (the root label)?

So yeah, my general vote goes to at least splitting them up; one list
for configuration, one list (or item) for lookup matching (or
lookup-per-type-of-lookup, or however people want to call it, if that
is even necessary). And then we'd probably want something like 'if not
set at all, use best-match'.

Jelte

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+84qYACgkQ4nZCKsdOncXgFwCffZwoEmgW/SxfGxsT1V5nFWSv
aGYAmwcGlvwPKkyqdGDTiJLy9u8ECSNa
=jgi5
-----END PGP SIGNATURE-----