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

[JINMEI Tatuya / 神明達哉]

At Wed, 9 May 2012 10:32:48 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> 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>
>   )
> )

Ah, that's probably right - we won't be able to create a recursive
structure in the current JSON-style configuration (it's only nested).
It's more about how the underlying implementation constructs the
concrete client class.  Using this notation

class MetaDataSourceClient : public DataSourceClient {
...
private:
   vector<DataSourceClient*> clients_;
};

If the client_ vector can contain itself, there'll be a risk of
infinite loop.  But that won't happen as long as they are created from
the JSON configuration.

> > 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.

I agree we should ensure the same matching policy should apply to both
xfrout and auth (I guess you meant auth by "than bind10" above).  But
to me it's more about configuration matter than the underlying API.
I'd still imagine we'd like to have an ability of iterating over the
stored data source(client)s in some way.  But among other points, it's
currently just a speculation.  My main point in this context was that
the container approach provides that possibility as an API - if we
don't need it we don't have to implement it.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.