[bind10-dev] Enabling the user interface

[张立坤]

>Shane write:
> Configuration User Interface
> ----------------------------
>
> I expect the user interface to BIND 10 will allow administrators to set
> these attribute/value pairs. So, you will be able to add a master to a
> server by doing something like:
>
>   
>> get auth/zones/example.org/masters
>>     
> 192.0.2.1 192.0.2.2
>
>   
>> set auth/zones/exapmle.org/masters="192.0.2.1 192.0.2.2 192.0.2.3"
>>     
> attribute "auth/zones/exapmle.org/masters" does not exist
>
>   
>> set auth/zones/example.org/masters="192.0.2.1 192.0.2.2 192.0.2.3"
>>     
> attribute "auth/zones/example.org/masters" set
>   
Although, the Restful way is quite flexible but less user-friendly.  The 
problem is that the path is too long which will cause the following problem.
1 It will be hard to remember
2 User has to input too many letters which is very error-prone.
 
Basically, the things which can be configured by the administrator 
should be categorized into several type (like class), and the entity 
what we want to configure is like instance of these classes.  And what 
we want to change is the attribute of the instance.

Take zone as one example. If currently, there are two zones in the 
server, which are example.com and food.com. It will be very convenient 
and expressive if administrator can use the following way to modify 
their attribute
zone(example.com).master = "192.0.2.1".

And for each module, it will have one or more classes.  For each class, 
it should have at least two "class method" like "child" or "instances" 
to return current instances, and "attributes" to return the attribute 
name and type of its instance. So for the above example, if 
administrator wants to modify the attribute of zone food.com , he can do 
something like this
zone.attributes //which will return "attribute : name master , type string"
zone.instances //which return "example.com food.com"
zone(food.com).master = "192.0.2.2"
this also require that each class has some way to identify its instance, 
through name is one possible solution.

And at the background, Bigtool should interpret the command into several 
get and set
> There are advantages of such a configuration and user interface
> mechanism:
>
>       * It allows a new component to be added without having to change
>         the user interface tool(s). This is important to allow people to
>         change BIND 10 to meet their needs without having to do a lot of
>         work.
>       * Writing the user interface is very simple. Only a very small set
>         of operations is needed ("list", "add", "get", "set", "remove").
>
> However, while this is infinitely flexible, it is also relatively clumsy
> and hard to use.
>
> It also does not support a number of non-configuration related commands
> that will be necessary. For example, starting/stopping the server,
> requesting a fresh zone AXFR from the master, or re-signing a zone.
>
>
> Towards a User Interface
> ------------------------
>
> We need two things:
>
>      1. A way to define sets of configuration changes that are more
>         natural to the administrator.
>      2. A way to define non-configuration actions.
>
> I think it makes sense to define "administrator actions".
>
> Each component can define as few or as many of these as necessary. This
> would probably be done in a configuration file (which will end up being
> XML at some point, although maybe not written as such).
>
> So we may have something like:
>
>         Action: AddMaster NAME DATA_SOURCE [ACTIVE=False]
>         Description: Add the zone. Unless specified, the zone is not
>         served until activated.
>         
> A component will define these, then the UI will get them at runtime
> (either from the component itself or from a central configuration
> component).
>
> The UI can then tell the user what actions are available, and give the
> user details about the syntax and meaning. It can deliver the request
> for an action using the c-channel, and the component will then have all
> the information it needs, syntax checked. The result will be returned
> using the c-channel.
>   
In addition to return the attribute of some instance of one class, we 
still need some way to return the actions(class or instance methods), 
the class method like "class methods" and "instance methods" which 
return all the action can be done by one class and the instance of this 
class.

>
> That's the basic idea. It has some rough edges (clearly), so feel free
> to point out problems or propose alternate solutions.
>
>
> For example, it may make sense to arrange actions so that they are
> grouped:
>
>   
>> add zone example.info type=master
data_source=zone_file:/var/bind10/db.example.info
>> add zone example.net type=slave masters=192.0.2.1,192.0.2.254
>> add zone example.com type=master
data_source=sqlite:/var/bind10/sqlite.example.com
>>     
>
>   
For add or delete instance of one class, the class should have class 
method "add" and "remove".
Use the configuration way mentioned before, we can get the same result 
by use following command
zone.add(example.info)
zone(example.info).type = master
zone(example.info).data_source = zone_file:/var/bind10/db.example.info

This is just a general idea, from implementation perspective there maybe 
have some issues. But if every command is stateless, I think it won't be 
too hard to implement.

Feng
CNNIC