Re: inetd enhancements - config syntax

[James Browning <jamesbrowning137%gmail.com@localhost>]

>That's not the only use for escapes.  From a theoretical and aesthetic
>perspective, it would be nice to be able to get arbitrary octet
>sequences into arguments; as outlined, for example, it's not possible
>to get a newline into an argument.  (Well, _almost_ arbitrary octet
>sequences.  Until and unless the underlying C issues are fixed or
>worked around, zero octets will have to stay reserved as terminators.)

We will definitely consider adding some escape sequence functionality
to the syntax. At this point for us it more of a question of time constraints,
but we like your idea about octet sequences. Since it seems that current
implementation of inetd doesn’t support escape sequences, we may not 
implement this right away.

>Cycles...mayyyybe.  Multiple levels of includedir - what's wrong with
>that?  That is, why is avoiding it a Good Thing?  Forbidding nesting
>includes strikes me as instance of preventing stupid things and thereby
>preventing clever things.

Our reasoning behind not wanting multiple levels of includedir was to avoid
overly complex or messy configuration systems, but we see your point. If time
allows, then we will implement cycle detection.

>I also don't like the only form of include being include-a-directory;
>in my estimation, that wires too much policy into the mechanism.  I
>would prefer to see either two include directives, one for directories
>and one for files, or a single directive that somehow subsumes both.
>(Two ways come to mind immediately.  (A) if the argument names a file,
>it's a file include; if a directory, a directory include.  (B) to
>include files in a directory, write something like "include dir/*" or
>"include dir/*.conf" or something of the sort.  Though there is the
>conflict with a possible service named "include" - perhaps ".include"?)

We like the idea of being able to include files along with directories. Our
current plan is to implement directories first, along with files if time permits
us. If we don’t have time to implement include-a-file, then we will make sure
our include-a-directory implementation can easily be extended to support fies
in the future.

>inetd.conf already supports per-service overriding of the listen-addr.
>According to cvsweb, this went in 1996-12-30 (inetd.8 rev 1.8, inetd.c
>rev 1.16).

It’s true that inetd currently supports specification of the listen-addr, 
however, the way it currently functions is that when [listen-addr:] is used, 
it changes the default listening address for all services in the remainder of
the conf file, or until it is changed again (meaning that if you only want to 
set a specific address for one service, you will need to use [listen-addr:] 
twice, once to change the listening address, and again to change it back). In 
our new syntax, we think a service should be able to change its own listening
address (with a key-value pair) without changing the “global” [listen-addr] 
value. 

Thank you for your input,
inetd Team