Re: [Gnu-arch-users] Features command for arch

[James Blackwell]

In lists.arch.users, you wrote:
> On Sat, 2004-08-28 at 12:17 -0400, James Blackwell wrote:
>> There's the easy way to do this, and the hard way to do this. I'm inclined
>> to implement the easy way. The easy way is to in libarch implement a
>> handful of arch_features functions along these lines: 
>

David Allouche:
> What does "hard way" you have in mind looks like? I'm not asking for a
> complete specification, just a glimpse so we can see where it stands
> with respect to the "easy way".

The hard way would involve some sort of query/answer getup in which one
part of the library would ask the other parts of the library for what it
can and cannot do.

>> EXAMPLE OUTPUT:
>> $ tla features
>> tla-features-begin
>> file-id-escaping:1
>> archive-checksums:2
>> tla-features-end
>> (always a return code of 0)
>
> As Andrew pointed, the "tla-features-begin" and "tla-features-end" lines
> are noise.
>
> For the sake of discoverability, I think we should change the output
> format from:
>
>     <nickname>:<revison>
>
> to
>
>     <nickname>:<revision><white><summary>
>
> where <white> is one or more tab or space and <summary> is a short
> (limited to 40 or 50 characters) description of the feature in natural
> language, similar to the the synopsises in "tla help", so we have a
> useful "tla features | grep" idiom.

Ok.
 
> To simplify scripting, you can also add a "feature --quiet" option to
> omits the whitespace and summary.
>
>> $ tla features file-id-escaping
>> 1
>> (with a return code of 0)
>
> Similarly, subsequent lines of output may contain the summary and a
> paragraph-long description of the feature. A --quiet option would yield
> the output you described.

More than I want to do.

>
>> $ tla features archive-checksums 1
>> (return code of 0)
>> 
>> $ tla features archive-checksums 3
>> (return code of 1)
>> 
>> $ tla features nonexistant-feature
>> (return code of 1)
>
> I do not see the need for additional natural-language output in those
> cases.
>
> The rationale for the additional natural language output is to be self-
> documenting, allow new users to understand what each feature means, and
> allow us all seasoned tla users to find the specific nickname for a
> known feature when there will be dozens of them.

I'm already sold on the "short sentence part". I don't like the
"paragraph" part.

>
> Of course, this suggestion has little value if developers and
> maintainers are not willing to enforce the quality of the natural
> language descriptions of features.

patches welcome. ;)


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400