[bind10-dev] configuration diffs

[Jelte Jansen]

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

On 05/15/2012 10:22 AM, Michal 'vorner' Vaner wrote:
> 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.
> 

I am currently in a state of mind of fully open discussions, so either
is fine :)

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

True, and indices would also allow for better matching (currently you
can only match on the complete item). However, it would increase the
fragility of data getting out of sync even more (or rather, should
data get out of sync, it would be much more destructive). But I
suspect we'll have to use indices in some form or another anyway.

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

Ack. Another issues which is currently conveniently overlooked by
simply rewriting the entire list :)

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

Ack, and I would still like to preserve the option to just retrieve
'current' data on-the-fly (for items that require no actions upon
change, and for code paths that have no time-sensitive application).

So, perhaps there may be three levels here;
1 do nothing during the actual change, but have full access to current
data
2 get a full set of changes when they happen.
3 provide the ability to tie specific callback to specific changes for
specific items

The important thing is to get a reliable changeset. 3 may indeed be
more of a potential convenience thing.

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

iEYEARECAAYFAk+yL7IACgkQ4nZCKsdOncU0sQCg0oBmC6wYY3rknVzju8iZWBWx
cYQAoI0eG4lTGF+W0K4zzjrK1632WVlz
=z4Jo
-----END PGP SIGNATURE-----