Re: [Freeipa-devel] Optionistic approach for new DNS API
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. 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 ipa dnsrecord-del ZONE NAME --type=mx \ --rec-data=10 server1.example.com. 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. - 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. 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. - 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. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Optionistic approach for new DNS API
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 copypaste 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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Optionistic approach for new DNS API
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 copypaste 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.
