[bind10-dev] config data api

[JINMEI Tatuya / 神明達哉]

At Fri, 13 Apr 2012 10:56:48 +0200,
Jelte Jansen <jelte at isc.org> wrote:

> > This sounds you want to replace both the specifications and the
> > actual data with classes. I find it really user friendly the data
> > itself (parameters to commands, configs, etc) are the raw python
> > primitives, as they are much easier to handle.
> 
> Yes that was part of the idea, though I was thinking of having a
> getValue-like call in the that returns the primitives for this.
> 
> > We probably could make the lists iterable and the maps [ ]
> > indexable, etc, but is there really a need? Or can the dict/list be
> > inherited to add some more functionality to them?
> 
> AFAIK, you can assign anything to anything in python, except to
> primitives, so no. But we could indeed duck-type their primitives'
> behaviour on top of these. Not sure if we should, though, it would add
> a lot of potentially confusing implicitness.
> 
> We can of course start out by skipping all of this and just doing the
> specifications classes and see if that makes it all easy enough :)

Right now I don't have a fixed opinion on the appropriate abstraction
level for these notions.  But, in general, this seems to be a common
tradeoff issue between the flexibility of lower level representation
and the safety provided by higher level interfaces.  If the
application can have full access to the most low level representation
it's sometimes easy and can complete missing features by manipulating
the data itself.  Getting the "default" value may be one such thing.
On the other hand, if any application can get access to the lowest
level implementation, all others need to worry about various corner
cases such as the configuration integrity is magically broken in the
middle of a process.  To make the system safe in such an environment
the implementation will be more complicated.

The appropriate abstraction level will depend on detailed usage cases,
and some f2f discussion with a whiteboard may help.

---
JINMEI, Tatuya