[bind10-dev] Datasources, meta-datasource and configuration

[Jelte Jansen]

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

> 

>> - in-memory could be also used for xfrout (using AXFR) as long as
>> it provides the iterator interface.
> 
> If we have the shared-memory version, then yes, it could. In the
> current state, it looks wrong to load the whole zone by iterating
> into memory and then iterate the memory copy again to send it.
> 
> But if we use it in xfrout to iterate, we may just use it
> everywhere for simplicity. Then it could delegate the request for
> updater to the data source where it loaded the zone from and we
> would not have to care about providing separate ways to choose the
> datasource for auth and for the rest.
> 

Right. I also think it would only make sense if xfrout has access to
an *existing* loaded in-mem interface. And if that access is there, it
would not really make sense to load the records from the database. If
that access is not there, it would not really make sense to first load
them from the database and then iterate of the memory structure :)

>> - maybe it's too early to talk about the implementation, but 
>> personally I'm not convinced that the best way to implement it is
>> to make the "meta datasource" as an interchangable derived class
>> with other data source (client) classes.
> 
> Well, my motivation for it is that the metadatasource would need a
> single method implemented only, therefore we would need very little
> changes anywhere else. And in case there's only one data source, we
> could just bypass the selection completely. But I'm open to other
> approaches, of course.
> 

I guess the alternative would be to code the behaviour into some fixed
class which is used instead of the datasource itself, I guess it would
depend on the signature of that one method (and on whether it would
need any other methods (that 'normal' datasources do not need).

>> - I'm not sure if I understand the "single match" type usage.
>> But in any event, I guess it's subject to discussion how we
>> realize that different components can prefer/exclude particular
>> types of data sources.
> 
> Well, the single type would mean „Take the first data source in the
> list and ignore the rest“. In case we are serving from in-memory
> only, but have some other datasources to load the zones from, we
> want to make sure we never query the datasources, because that is
> slow ‒ even in case a query for a non-existent zone comes. So the
> in-memory would be placed first, the rest of datasources would be
> used to load the zones only and ignored by the matching mechanism
> (or, the matching datasource mechanism could be just skipped, as
> mentioned above).
> 

I wonder if a single selection mechanism setting is enough. I hope so
:) (first-match may be tricky in terms of expected behaviour when
there is no complete match)

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

iEYEARECAAYFAk+RW3sACgkQ4nZCKsdOncXfFgCfYmYuf6yQ5YBtPaBIVadPSioQ
28cAoJU52x9Q+U5mC2KMqlf4USzBy9kl
=myvR
-----END PGP SIGNATURE-----