[bind10-dev] reminder: meta data source vs data source container (summary)

[JINMEI Tatuya / 神明達哉]

I suggest we conclude this discussion in the biweekly call tomorrow.
Assuming participants will understand the basic design tradeoffs,
we'll basically just have a quick voting to see if there's a majority,
and, if not, will just pick up either one by tossing a coin.

Detailed version of the technical discussion is at:
https://lists.isc.org/pipermail/bind10-dev/2012-May/003410.html

---
JINMEI, Tatuya

At Mon, 07 May 2012 17:15:02 -0700,
JINMEI Tatuya <jinmei at isc.org> wrote:
> 
> In the f2f meeting we discussed two options for implementing the
> concept of "set of data source(client)s": A "meta data source
> (client)", which will be a derived class of DataSourceClient, and a
> separate "container" class that holds the set of data source(client)s.
> 
> This is a higher level summary of major pros and cons of these
> approaches, which I promised to send to the dev list at the meeting
> (I'm trying to be objective, but I'll be quite likely biased because I
> have a clear preference):
> 
> - pro for "meta": existing code that uses abstract data source client
>   interface won't have to be changed
> - pro for "meta": existing code that instantiates data source clients
>   using the polymorphic factory won't have to be changed (although in
>   practice there's less such code right now).
> - pro for "meta": the amount of code to be added will be smaller.  In
>   particular, we won't need to add a python wrapper.
> - pro for "container": the application can have finer control about
>   the underlying set of data sources (such as iterating over them by
>   itself to find a specific data source that matches complicated
>   conditions).
> - pro for "container": we will be able to extend the base client class
>   more freely, without worrying about breaking the existing
>   deployment.  It will also be possible to migrate to the "meta"
>   approach with keeping compatibility.
> 
> There are other small differences, but overall, it seems to me to be
> the choice between the initial implementation cost vs extendability.
> The "meta" approach will require less code to complete from where we
> are now.  But it will introduce another constraint in the base class
> and will (possibly) limit some types of future extensions to the base
> class; the container approach doesn't have this problem, and we can
> switch to the meta approach later if it turns out to make more sense.
> 
> To keep this message (which is expected to have more readers) shorter,
> I'll stop here for now.  I'll send another message for more detailed
> discussions.
> 
> ---
> JINMEI, Tatuya
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev