[Freeipa-users] Optionistic approach for new DNS API

[Martin Kosek]

On Thu, 2011-12-15 at 15:20 -0600, Endi Sukma Dewata wrote:
> On 12/14/2011 3:41 PM, Martin Kosek wrote:
> > ipa dnsrecord-mod ZONE NAME VALUE? --type=mx --preference=0
> > ipa dnsrecord-del ZONE NAME --type=mx --preference=0 --exchanger=server1.example.com.

Thanks for comments Endi! Please, see my input bellow.

> 
> I think the mod & del commands should use the same way to specify the 
> existing data.
> 
> If we use the raw data, it should be specified as an option instead of 
> an argument:
> 
>    ipa dnsrecord-mod ZONE NAME --type=mx \
>      --rec-data="10 server1.example.com." --new-preference=20

I was also thinking about using current param "--mx-rec":

    ipa dnsrecord-mod ZONE NAME --mx-rec="10 server1.example.com." \
      --mx-preference=20

But this would be a misuse and unexpected behavior. A new option would
be better for that.

> 
>    ipa dnsrecord-del ZONE NAME --type=mx \
>      --rec-data="10 server1.example.com."

Current command can do that:
    ipa dnsrecord-del ZONE NAME --mx-rec="10 server1.example.com."
We have this behavior for free.

> 
> Alternatively we can use separate option for each parameter:
> 
>    ipa dnsrecord-mod ZONE NAME --type=mx \
>      --preference=10 --exchanger=server1.example.com. \
>      --new-preference=0
> 
>    ipa dnsrecord-del ZONE NAME --type=mx \
>      --preference=10 --exchanger=server1.example.com.
> 
> Or we can support both.

I think I would implement the first option first. We can extend if we
see it is useful. My point is that I don't think use would bother
constructing structured DNS record from its options in dnsrecord-del/mod
(fill --preference and --exchanger) but rather copy&paste raw DNS value
or use the interactive mode.

> 
> > - SHOW and FIND commands do not need this new --type parameter
> 
> We can also add --types to specify the record types we want to get back 
> in the result. This could be useful in case we want to refresh a certain 
> table only in the record details page. Low priority.

Ok, noted as an idea for enhancement. I would rather like to create a
functional minimalistic API first and add all the bells and whistles
later when we see it is useful.

> 
> BTW, I'd rather use --rec-type instead of just --type because 'type' 
> seems to be more generic. In case a certain DNS record type also has a 
> 'type' parameter, it might conflict with that. Another possibility is to 
> use a prefix for all type-specific options, e.g. --mx-preference.

Actually, I was discussing this with Honza today. The problem is that we
can't add conflicting options to one command (e.g. --preference for MX
record and --preference for KX record). We would have to use
--mx-preference and --kx-preference anyway.

This would also remove the necessity to use --rec-type at all. I think
we could detect the type from the options that were passed. I.e. when
the following command is passed:

   ipa dnsrecord-add ZONE NAME --mx-preference=0 --mx-exchanger=server1.example.com.

We know that MX record is being created.

> 
> > - ADD command:
> >    - when no option is passed to dnsrecord-add command, it may ask for
> > --type and then for the options specific for the particular type
> > - MOD command:
> >    - when no option is passed to dnsrecord-mod command, it may provide a
> > list of current DNS record values and ask for specific DNS record parts
> > to be changed for chosen value
> > - DEL command:
> >    - when no option is passed to dnsrecord-del command, it may provide a
> > list of current DNS record values remove the chosen value
> 
> For consistency the mod & del commands can also ask for the type, then 
> show the list of records in that type. This way the list can be shown in 
> a nicely formatted table rather than just raw data.
> 

IMO the interactive help I described is more effective - use just has to
choose a record and start modification for a specific RR type. With your
proposal, he would have to choose a type, then choose a record of that
type and then start the modification - 2 steps instead of 1. (And I
don't think that formatting nice tables with records in CLI would be a
priority).

Martin