[bind10-dev] meta data source vs data source container (detail)

[Michal 'vorner' Vaner]

Hello

(Sorry, Jinmei, for the duplicity, I forgot to send it to the list)

It seems you're slowly beginning to persuade me the container may be better in
the long run. However, with two small exceptions:

On Mon, May 07, 2012 at 05:18:47PM -0700, JINMEI Tatuya / 神明達哉 wrote:
> (I'm not sure what should happen if "backend" also contains "meta"
> type; a naive configuration and implementation would subsequently
> cause an infinite loop).

Well, it would not be an infinite loop. It would be a different instance of the
meta data source, with possibly different matching strategy. So we could combine
things like:

meta <first match> (
  in-memory
  meta <best-match> (
    db <sqlite3>
    db <mysql>
  )
)

> With the "container" approach, we can provide applications with
> greater options of manipulating/examining the underlying data
> source(client)s (of course, at the cost of having applications be
> aware of the concept of the container).  For example, it will be
> easier to find a specific data source (client) that has a zone that
> exactly matches a given zone name.  This will be necessary for xfrin
> to check the SOA serial of the zone before attempting the transfer.

I'm not sure we want to allow too much control there. I would hate to see
problems that xfrout uses a different matching strategy than bind10, so
transferring a different data than sending answers for. That could be a real
nightmare for an administrator to debug. If we just provided the same
configuration and it worked the same, we couldn't make such a bug by accident.

With regards

-- 
If you let 100 monkeys type, eventually one will write a Java program.
The rest code in Perl.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120509/8fa25346/attachment.bin>