Re: inetd enhancements - config syntax

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> The new syntax would look something like:
> <service-spec> on/off key1=value, key2=value1 value2 value3,
> key3=â??this is a valueâ??, key4=value1 value2 â??this is value3â??;

Hm.  I think this is about as good a new syntax as we're likely to get.
In particular, it offers a fairly wide variety of extensibility
possibilities for the future.

> There are some lingering thoughts and questions we have regarding
> implementing this new syntax. 

> Firstly, we are unsure if we should implement escape sequences for
> arguments contained inside quotes.  [...]  Would it be useful for us
> to support escape sequences in the new syntax?  (In other words, is
> there any use for being able to pass quotation marks as part of an
> argument for a service?)

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.)

And, if it is ever extended to, for example, support compound values
with something like key={...}, there will still be a way to get the old
semantics if there is a uniform quoting mechanism.

> For â??per-serviceâ?? (really just â??externalâ??) configuration
> files, our current thought is to allow for the â??includedir xâ??
> directive (includedir is not necessarily the directive we are set on)
> inside of inetd.conf where â??xâ?? would be a directory containing
> fragmented configuration files.  But we are also thinking it would be
> best to not support â??includedirâ?? inside the fragmented files
> themselves, in order to avoid potential cycles and to avoid multiple
> levels of includedir directives.

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.

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"?)

> Regarding the [listen-addr:] option, our current idea is to leave
> this functioning as is (which is that it acts more like a global
> variable and sets the listening address for the rest of the config
> file).  We would also like to introduce a new key value pair,
> listen-addr=xxx.xxx.xxx (or an IPv6).  This would allow for the
> listening address to be overwritten only for the service that
> specifies it.

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).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B