[bind10-dev] configuration diffs

[Michal 'vorner' Vaner]

Hello

I'm not sure if I should be answering the email or if I'm addressing the main
ideas of it. Maybe these are just random follow-up ideas.

On Mon, May 14, 2012 at 04:47:09PM +0200, Jelte Jansen wrote:
> For example, if you have a data element of type list, and you get an
> update, the updated value is either:
> A) a list itself; signaling that the list is to be replaced completely
> B) a map containing:
>    1) "removed": <list of removed items, complete matches>
>    2) "added": <list of added items, complete matches>

I don't really like this representation. It looks strange. Also, two things:
 • I'd prefer removing items by their index instead of their value. It does not
   require to search the list, the index could be a lot smaller than the item
   itself and in case we have multiple same items (I know this is not allowed
   now, but I don't think it makes sense when it is a list).
 • What about preserving order? Is it possible to add somewhere in the middle? I
   know it is not possible by current bindctl interface, but I think this is
   more the limitation of the tool than of what we should be able to do. We want
   to be able to insert an item in the middle of an ACL or like that.

> Nice in theory, but given that we are talking about data that should
> be synchronized, this all gets more and more fragile. Even more so
> since all these moving parts work with 'raw' data (Element objects on
> c++ side, and basic types in python). It was already kind of over the
> limit of readability there, and this would probably push it deep into
> mount doom itself.

+1

> So, for instance, instead of a general ConfigHandler method, one would
> set up actions to be called when values are changed, added, or
> removed; should one not want to do that, I would still like to be able
> to read data directly (from 'current' config).

I think a generic config handler is better, because then the ones that don't
care about changes (it is a simple item or a short list or something) don't
really need to construct it from multiple methods. Also, we might want to do all
the changes „atomicaly“ somehow from the differences, so it should be inside the
same method. I think it is better to have one function call and pass some kind
of change description to it.

Maybe, if we were into easy of use of the API, it would be pretty nice to have a
callback on each configuration item, so we don't need the large
handle-any-config function. This is hard to extend ‒ and we are planning on
having hooks, these just can't change the function.

With regards

-- 
How many Lisp programmers does it take to change a light bulb?
(((H)mmm,) (I'm ((not) sure, better))) (find (out))...

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120515/51e0e69c/attachment.bin>