... | ... | @@ -47,5 +47,20 @@ Status update 1: |
|
|
* Convert initial zone loading to use FULL zone_update.
|
|
|
* Other than these, we shall see. The JK's original zone-api branch contains many bugs and unfinished parts. I also have my doubts about usefulness of some.
|
|
|
|
|
|
Status update 2:
|
|
|
* What has been done:
|
|
|
* Improved changeset, checks for redundancies and eliminates them. Note: it compares the RRs fully, so it cannot eliminate a redundancy when you don't specify the RR exactly (e.g. DDNS lets you set class to NONE and TTL to 0, I think, to remove an RR). Code cleaned up.
|
|
|
* Added FULL update. Both INCREMENTAL and FULL updates are used in ctl to setup/edit zones.
|
|
|
* Added read-only iterators. Editing the zone requires you to first finish old iterator and start a new one afterwards. Writing iterators required either another zone_contents structure with edits or constant index rebuilding. Nowadays hattrie can rebuild indexes automatically when needed which would make these iterators read/write - but I haven't tested this.
|
|
|
* Enhanced API - allows removing whole RRSet of specific type or the whole node.
|
|
|
* Next steps:
|
|
|
* Experiment with integrating apply_ API into zone_update. I have done that in the `zone_update-v2` branch. Tests are looking good, but I'm not 100% sure the approach cannot diverge from the old way of changeset application.
|
|
|
* This step includes making parts of the apply_* code public.
|
|
|
* Replace the changeset with a list of changesets. Required for IXFR.
|
|
|
* *WARNING:* IXFR uses the STRICT option with apply_init while DDNS does not. It is required to add similar option to propagate it into zone_update if it is to be integrated into IXFR.
|
|
|
* Of course integration with zone-loading and AXFR still remains on the TODO list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**Feel free to add whatever you want, and/or edit what's already here.** |