Env vars next generation

[Maciej Katafiasz]

Hi hackers,
This is something I've got on my mind for a long time, and finally got
around to writing up something more concrete. I intend this post to be
sort of brain-storming, ultimately leading to design and implementation
of system that would fully supersede current mechanism of environment
variables.

Environment variables, as they stand today, have number of issues
inherent to their design, as they go back as far as first Unix versions
(I think), and this shows. While simple and undoubtly useful, this
30-years-old facility simply doesn't stand up to all the task we throw
at it today.

All the shortcomings of envars can effectively be reduced to single (or
one-and-a-half :) problem: they are entirely static. The only time you
can effectively influence program's environment is its startup (or, from
user's POV, even *before* startup), there is no way you can change them
after the program has been initialised, unless there are special means
implemented in given app, and additionally envars only take effect via
process inheritance, so there is no way to set session-global envars
other than setting them before the session even starts. This is clearly
insufficient for passing various, often crucial settings to modern-world
apps, where we've come to expect our apps to adapt to changing
environment. With immutable env vars, this is obviously impossible :).
Not to mention it goes totally against user's workflow, forcing them to
specify all their needs before they have them.

What I'd like to see is system that addresses current shortcomings,
while retaining all of the good things in envars. Those good things
would be:

* transiency -- in fact, this proposal seeks to strengthen that
attribute even more, by giving ability to change envars at runtime. It's
important to note that envars are purely temporary, they don't represent
anything storable, just the environment -- sum of all current
circumstances app works in

* (ability to) per-app operation -- you can set envars individually on
per-app basis, and generally in no connection with any other processes
in system

* tree-like structure and inheritance -- while currently limited to
execv() time, ability to inherit environment over from parent is
extremely useful and handy

* simplicity and ubiquity -- while introducing changing environment into
any design will more or less turn it upside down, potentially
introducing complexity, there's no reason to make the mechanism itself
any more complicated than current envars. As to ubiquity, surely it
won't get everywhere the day it's written, but whatever solution we come
up with, it should be portable to every OS that has notion of envars

Note that above exclude using any existing solution available right now,
like GConf, since to my knowledge none has all or even most of
properties listed. GConf for example cannot make setting be
per-app-instance, cannot create ad-hoc hierarchies, etc.

Implementation of these "env vars next gen" (thereafter called EVNG)
would ideally find its way into OS kernel, just as today's envars did.
This is however only doable in open source systems, and immediately
precludes any proprietary Unix or other system from taking that route.
Therefore, we would need some wrapper library interested apps would link
against, that would interface between EVNG implementation suitable for
particular OS and app, presenting consistent. portable API to use. Other
possible implementations include daemon process + socket / IPC
communication, or maybe some OS-specific facilities suitable for use
here. I have no clue really as to what's available on different OS's out
there, which is partly why I send this to XDG -- in hope it'll find
audience experienced enough to be able to invent something that'll work
for everyone.

Another implementation aspect is change notification delivery method --
should it be synchronous or asynchronous? Async notification (like Unix
signals, and whatever is there in Win32 or other OS's) has the advantage
of working for apps without mainloop, but disadvantage of being more
complex from implementation POV when EVNG are implemented outside of OS
core, and also of introducing potential re-entrancy problems inside apps
getting notifications. Synchronous delivery solves these issues, but
introduces need of constant select() loop, which not all apps might
have. Realistically, though, it's somewhat hard to imagine app without
mainloop reacting properly to environment changes, so that might be
non-issue in fact.

That'd be all in initial thoughts department, I hope someone with actual
clue as to how it might work will pick up discussion and implementation
so we can get env vars matching rest of our 21st century technology :)

Cheers,
Maciej

-- 
Maciej Katafiasz <ml at mathrick.org>