[bind10-dev] addZone interface for the new loadzone and zone management framework

[JINMEI Tatuya / 神明達哉]

I've just created two new tickets that may have to be pushed into the
current sprint:
http://bind10.isc.org/ticket/2541
http://bind10.isc.org/ticket/2542
See the description of the former for background information.

In the short term, we need to decide whether to take this path or add
some sqlite3-specific quick hack to the loadzone code itself.  If we
choose the former, we should probably lower the priority of some of
the existing tickets of the sprint.  Possible candidates would be:
#2500 (SOA RDATA support), #2440/#2441 (merge/order-free load for
in-memory).

For a longer term, I think this is related to how we manage zones in
data sources and how to implement it, including deleting/listing zones
and supporting zone related configurations (primary vs secondary, list
of primary servers in case of secondary, zone specific ACL, etc).
Personally, I don't believe the JSON style configuration data are
sufficiently scalable to support such information for millions of
zones, and that should go to a separate (conceptual) database.  And,
for real DB-based data sources, it would be natural to store this
information in the same DB as that stores other zone data.  If we take
this approach, I suspect the feature set of managing zones will be
beyond the scope of the concept of data source client, and
implementation-wise we'll need another class.  As such I'm personally
a bit reluctant to do #2541 at this point, but of course this
discussion is debatable in the first place.

Another note related to the topic (but basically orthogonal to the
previous point): if we separate the operation of adding a zone and
the operation of loading zone data (e.g, not within the same DB
transaction), there will be a period when a server recognizes the
existence of a zone without its content.  Then, until the load is
completed the auth server will return SERVFAIL to queries for the
zone.  This is probably not the wanted behavior, and I guess we'll
need to provide some way to make both operations atomic.  It will
probably affect some of the interfaces we are currently developing.

---
JINMEI, Tatuya