On 9/22/2011 7:24 AM, Martin Kosek wrote:
2) Some DNS records may be pretty large. MX record data is small, but
for example CERT records have an entire certificate stored in it.
Wouldn't there be a problem if we place the large DNS record in URL?
This is how the DNS record list page could be redesigned:
http://edewata.fedorapeople.org/images/dns-record-list-page.png
It should resemble what you see in the zone file. The content can be
obtained with a single dnsresource-find operation.
If you click one of the data, it would open a dialog box for that
particular record type. We will use the raw data as a primary key to
execute the dnsresource-<rrtype>-show command. Each attribute in this
record type will be displayed in separate fields:
http://edewata.fedorapeople.org/images/dns-record-edit-dialog.png
When you save it will call dnsresource-<rrtype>-mod and put the values
in separate parameters. It will still use the original raw data as
primary key, but we don't need to encode the new values into raw data.
If we use a dialog box like this none of the attributes need to be added
into the URL. It will be passed internally via variables. If we use a
separate edit page (with a unique URL for each record), we might need to
specify the entire raw data in the URL, but maybe we can find a
workaround for CERT record. I'd prefer to use a dialog box because it
can be used for both add and modify.
OPEN QUESTION: should we implement these new commands also for discrete
DNS records types to be consistent? I mean for example A, AAAA, CNAME,
PTR, ... They would look like
ipa dnsrecord-aaaa-add --ip-address=IPAddress
BENEFITS of this approach (command per RR type):
- use can get all help for RR type by simply typing "ipa help
dnsrecord-mx-add"
- we would be able to implement helper methods consistently on one
place, for example:
dnsrecord-aaaa-add --from-mac=00:1D:BA:06:37:64
If we have this for all record types the UI can use a generic code to
figure out which command to use. Everything will be in this pattern:
dnsrecord-<rrtype>-add/mod/del <primary keys> [parameters*]
OPEN QUESTION: should we implement also -find methods
(dnsrecord-mx-find) so that UI can for example populate text fields for
all (MX) records for one DNS name?
Depending on the UI design, it might not be needed. But it won't hurt to
have one in case the UI changes, for example suppose we want to have
separate tabs for each record type.
4) -mod commands shall be implemented for structured RR types:
API would be almost the same as with -add commands. User (WebUI) would
just have to identify which record should be modified:
a) by copy&passing the raw DNS value directly to the command:
dnsrecord-mx-mod example.com @ "1 mx1.example.com." --preference=0
The Web UI will use the JSON-RPC version of this command. As discussed
already, the non-interactive mode for CLI will be useful for writing
scripts or other applications that will invoke the CLI/API.
Being able to specify the attributes in separate parameters means that
the client doesn't have to figure out how to encode the attributes into
a single raw data. They will be encoded consistently by the server.
b) (CLI only) by using an interactive wizard that would let user choose
the modified record like this way:
dnsrecord-mx-mod example.com @ --preference=0
Which record would you like to change?
[1] 1 mx1.example.com.
[2] 10 mx2.example.com.
DNS record:<user enters the number>
The interactive mode will be useful for people who have to use
text-based terminal.
--
Endi S. Dewata
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
