Re: [MirageOS-devel] command line arguments for unikernels

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

On 30 Nov 2014, at 21:52, Daniel Bünzli <daniel.buenzli@xxxxxxxxxxxx> wrote:

> Le dimanche, 30 novembre 2014 à 22:21, Richard Mortier a écrit :
>> On 28 Nov 2014, at 17:08, Daniel Bünzli <daniel.buenzli@xxxxxxxxxxxx 
>> (mailto:daniel.buenzli@xxxxxxxxxxxx)> wrote:
>>> ...I really like the idea that only what is really used in the 
>>> configuration file gets documented in the help or parsed from the command 
>>> line.
>> 
>> i have to say, i really don't. or at least, i suspect i would really want 
>> there to be some way that i could get, from the command line, documentation 
>> on the things that i haven't used in the configuration file but could've.
> 
> I think this is because you are mixing two things that should be kept 
> separate.
> 
> There's 1) the documentation of the particular instance of a configuration 
> system you are dealing with and 2) there's the documentation of the 
> configuration system itself (i.e. assemblage).  
> 
> For 1) it would be misleading and there's no point in exposing a 
> configuration option that has no effect. Besides it may be operated by 
> someone who doesn't care at all about 2) so you want to make his experience 
> optimal by not giving him information he doesn't need.
> 
> For 2) that belongs to the documentation of the configuration language which 
> in this particular case being an ocaml API is documented through ocamldoc 
> (here [1]). We could expose that in an alternate man page for assemblage, but 
> in general it's better not to dilute/replicate documentation in too many 
> places as it becomes painful to navigate and keep in sync. Besides in this 
> case you are already likely to use that ocamldoc generated documentation 
> anyway while you defining your configuration system.

well, maybe. it may just be that i'm misunderstanding how you envisage 
assemblage being used.

re 1-- i'm quite (indeed, very) happy to have this available to me, though i 
don't think i'd agree with quite the strength of your statements about exposing 
configuration options that aren't used ("misleading", "no point"). i don't know 
the assemblage configuration format at all, but if there are (as seems common 
with other formats) options that can override or interact with each other, then 
seeing whatever are the default values provided for those options when they're 
not explicitly used is rather useful. (particularly if those defaults ever 
change.)

re 2-- this seems more of a workflow thing (and remember, the user is always 
right ;) -- compare the utility of "man bash" to "man make" when writing shell 
scripts vs makefiles. (at least on all systems i've used recently.) having to 
get hold of a browser, google for gnumake, find the right gnu.org page and then 
search through it is a royal pain (even if the bash man page is hardly an 
exemplar of clarity or organisation).

-- 
Cheers,

R.

[ This address fails on Dec31. Use richard.mortier@xxxxxxxxxxxx subsequently. ]

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel