On 12/15/2011 4:03 PM, Martin Kosek wrote:
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.

I'm OK with either options. The help doc describes the --mx-rec option as a "comma-separated list of MX records". It doesn't say how the parameter should be used. We could say the mod command can be used in 2 different modes.

In the first mode (the original) the command modifies the entire record object and the --<RRTYPE>-rec is used to specify the new records.

In the second mode the command modifies a record specified in the --<RRTYPE>-rec. It also syntactically means we could perform the same modification against several records at once, although I'm not sure if it makes sense:

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

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

This is probably another reason to use the same --mx-rec option in mod.

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.

It might be useful for someone writing an application using the CLI. This way we don't need to know the order of the parameters.

It's a low priority, but we should plan what parameter names we're going to use in the future. If now we use --mx-preference to specify the new value, later when we implement the new mechanism we will need to use something like --mx-old-preference to specify the old value. I'd rather use --mx-new-preference for the new value.

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

OK.

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.

It probably depends on how it's actually implemented. I suppose it's possible to keep a separate list of options for each type-specific command, then merge the lists for the main dnsrecord-add/mod/del command while removing duplicates. But using prefix is OK too.

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.

Without the --rec-type, it's syntactically possible to add/mod/del multiple RR types at once. I'm not sure if we want to support that:

  ipa dnsrecord-mod ZONE NAME \
    --mx-preference=0 --mx-exchanger=server1.example.com \
    --mx-new-preference=1
    --kx-preference=0 --kx-exchanger=server1.example.com \
    --kx-exchanger=server2.example.com

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

The difference is not that big. Also if we keep the --rec-type option we can skip the first step:

  ipa dnsrecord-mod ZONE NAME --rec-type=mx

(And I don't think that formatting nice tables with records in CLI
would be a priority).

Table is a compact way to show the data while still describing what the values in the raw data mean.

  No.  Preference   Exchanger
  --------------------------------------
  1.   10           server1.example.com.
  2.   20           server2.example.com.

Without table we might have to label each value:

  Record #1
  Preference: 10
  Exchanger: server1.example.com.

  Record #2
  Preference: 10
  Exchanger: server2.example.com.

or just show the raw data without labels:

  1) MX: "10 server1.example.com."
  2) MX: "20 server2.example.com."
  3) SRV: "0 100 464 ldap"

My preference would be using the table, but the other options are still acceptable.

--
Endi S. Dewata

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to