[bind10-dev] datasources config

[JINMEI Tatuya / 神明達哉]

At Mon, 26 Sep 2011 09:27:15 +0200,
Jelte Jansen <jelte at isc.org> wrote:

> > Considering 1 and 2, I'd envision a higher level view like this:
> > 
> > - there's a system-wide configuration for "data sources" (not
> >   clients):
> > [ { type: "sqlite3", config: some way.. },
> >   { type: "inmemory", config: some way.. },
> >   { type: "static", config: some way..(or maybe no config here) } ]
> > - each application has its own configuration of data source "clients",
> >   which is per-class (and eventually maybe per-view when we support
> >   views):
> > for auth
> > [ { class: "IN",
> >     clients: [ { type: "inmemory" }, { type: "sqlite3" } ] },
> >   { class: "CH",
> >     clients: [ { type: "static" } ] } ]
> > for xfrin
> > [ { class: "IN",
> >     clients: [ { type: "sqlite3" } ] },
> >   { class: "CH",
> >     clients: [ { type: "static" } ] } ]
> 
> Just to make sure I get the idea here, so in effect a client like auth
> would see that for an IN query, it needs to check inmemory and sqlite3,
> it then takes the global configs for those and sets up clients?

"In effect", yes.  (From the API point of view it would be hidden in
the polymorphic factory).

> Not entirely sure what the use-case is, apart from more granular control
> over which modules have access to which datasources. If the latter is an
> important goal, i'd propose adding a 'name' variable to the datasources
> config too, and referencing that at the client lists, instead of the type.

The use case I was thinking about is that auth and xfrin would
probably use different sets of data sources.  Specifically, auth
would only need read-only interfaces (and preferably efficient ones),
so it would primarily use the inmemory client (sqlite3 was included in
the above example just in case).  On the other hand, xfrin needs
writability (but the access speed can be much slower) so the inmemory
client is of no use for it.

Such characteristics are local to each application (auth, xfr-in/out,
update, etc), so I thought it would be more natural to give the
application right to choose necessary interfaces.

But in any event, these are preliminary thoughts mainly as food for
discussion, rather than a strong opinion.

---
JINMEI, Tatuya