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:
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 mx1.example.com.
 10 mx2.example.com.
DNS record:<user enters the number>
The interactive mode will be useful for people who have to use
Freeipa-devel mailing list