[Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API

[Petr Vobornik]

On 12/02/2011 03:33 PM, Rob Crittenden wrote:
> Martin Kosek wrote:
>> On Thu, 2011-12-01 at 17:18 -0500, Rob Crittenden wrote:
>>> Martin Kosek wrote:
>>>> On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote:
>>>>>
>>>>> 3) The commands are in format dnsrecord<RRTYPE>-cmd, for example
>>>>> dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we
>>>>> want to go this way, I would have to bend the server framework a
>>>>> little
>>>>> which parses an LDAP object from the command name (LDAP object name is
>>>>> dnsrecordmx in this case). This is doable, although I am not sure if
>>>>> this does not have some implications in WebUI side.
>>>>>
>>>>> Martin
>>
>> Rob, thank you for the review! What do you think about the 3 open
>> questions I posted above?
>
> I haven't applied the patches to see what the output looks like yet so
> can't really comment on the first two.
>
> I think the extra dash would make the command line easier to grok, or at
> least read, but it isn't a show stopper for me. I'd be interested in
> feedback from the UI guys but they may have to start poking at it to
> really know for sure how much of an issue it would be.

For UI it is better without the dash. With dash it breaks the 
entity-method naming, which is default behavior for creating commands to 
the server. But it is quite easy to implement it with the dash too. If 
it makes the CLI more usable we should add the dash - it may save users 
more time.

>>> PTRRecord doc I think would read better as "The hostname this reverse
>>> record points to"
>>
>> Ok. Btw do you think it would be good to document this way all these new
>> DNSRecord part parameters? As I checked with Petr, these would be shown
>> in the UI - so the UI user would benefit from it. But it will require a
>> lot of writing and RFC study :-)
>
> I was wondering that myself. The labels can be rather terse, I wasn't
> sure how much more a _doc() would add. I was also wondering if we should
> include some of the limits within the doc, esp the 0-64k ones since
> those are smaller. It would make it somewhat inconsistent which is why I
> didn't raise it.

The label for attributes is very useful, without it we would have to add 
the label into internal.py which would only complicate things. The doc 
can be the same as the label as it is now for many attributes. Anyway 
special doc is useful if something is not clear.

>> Martin
>>> rob

-- 
Petr Vobornik