On 09/22/2011 08:31 PM, Endi Sukma Dewata wrote:
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:

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:

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
- 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*]

We won't have it for all types, so we will need a map. Most will use the old API, and a few will use the pattern above

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.

Find can return the original Data, and probably should. We only need the individual fields on edit, maybe on show.

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.

Freeipa-devel mailing list

Reply via email to