Single slave zone definition for two view (cache file name problem)

[Konstantin Stefanov]

On 18.03.2015 17:18, Matus UHLAR - fantomas wrote:
> rOn 18.03.15 17:10, Konstantin Stefanov wrote:
>> The issue is that named started to detect it since, if I'm not mistaken,
>> 9.7. It happened because such config was leading to bugs, but instead of
>> fixing the bugs, the whole feature was prohibited.
> 
> those bugs _were_ fixed: the in-view statement and prevention from using
> the same file multiple times (I remember discussion about issues coming from
> those here on the list).
> 
> you are complaining about your broken configuration worked.
> Sorry, I gave up arguing with you. 
Indeed, my configuration worked although broken. And now I can't make
the configuration as simple. Yes, the new 'in-view' makes the config
possible, but allowing simple configuration is a valuable feature in my
view.

Look at masters lists. You may write any config without it, simply by
repeating the same IPs where needed. But is masters lists a feature?
Ceratinly it is, it makes configuration easier and more maintainable.

The same is with my broken config. I am now able to have correct config
by repeating slave zones descrition twice.
But the feature 'ability to have only one description of common slave
zones' is now lost. And 'in-view' is not a substitution, as it again
requires two different description for one zone.

I'm trying to convey that in my view the feature here is not what
'in-view' solves. For me the feature that is lost allowed me to have
neat config.

A substitute could be, for example, some variable with view name to use
in file directive. If I could write somesthing like

zone "aaa" {
	type slave;
	file "aaa.$viewname";
};

that would allow me to write simple config again. Other variants are
possible, for example allowing different 'directory' option setting for
different views, as it again making possible to point to different files
with the same line.

I see developers' point and understand why reference to a zone (in-view)
is easier to program and debug than finding when referencing two
writable files is correct and when it is not, and programming checks.
And disabling referencing two writable files seems to be clever way,
especially since there is new 'in-view' feature.
For me as an user 'in-view' make sense with three or more views (than I
would have two descriptions, one full and one with in-view) for any
number of view.
But in case of two views (my case) in-view feature gives almost nothing.
I still have to have two files, and waht difference: two with different
filenames or one with filename and one with in-view. The script for the
first case is even simpler.

So again, for me the feature that worked is lost without any equal
substitute.

If you think that feature is of no real worth - OK, I don't know if
having exactly two views with a load of identical zones is a frequent
case. But the only thing I want to say - that there was a feature that
is now lost. Maybe that feature existed only by an oversight, but I used
it for five years, and it worked (for me, again).

And thanks for spending your time.

-- 
Konstantin Stefanov,

Research Computing Center
M.V Lomonosov Moscow State University