[pulseaudio-discuss] temporary vs persistent state data

[Damon Harper]

hi there!

i've just installed and set up pulseaudio and i am more than impressed
by it - bravo!  it is an elegant system and a much-needed one for the
unix world, i think.

i'm a bit of a weird masochist who rolls his own distro and packaging
system for a four-computer network, and i have noticed one problem
with the way pulse works when it is set up as a system-wide daemon -
it stores both temporary and persistent data in the same place
(/var/run/pulse by default).

for instance, the gconf data and volume-restore.table file *should*, i
presume, be maintained across reboots.  on my system, i use /var/run
strictly for temporary data like pid files and sockets and it is wiped
out at each reboot - so the persistent pulse data disappears.
normally persistent data should go under /var/lib or /var/state.

on the other hand, pulse's pid files and sockets *should* be treated
as temporary data and could be fair game to be wiped out if they
remain when pulse is no longer running.

i was initially going to set up a system of symlinks to take care of
this, but then i started looking at the pulse source.  my general idea
would be to split the PA_SYSTEM_RUNTIME_PATH up into two components,
one for temporary (/var/run/pulse) and one for persistent
(/var/lib/pulse or /var/state/pulse) files.  then each component that
needs to store files can choose the appropriate path.

complications:

- could affect existing programs?  but i don't think so, as most would
reference pid files and sockets which remain in /var/run/pulse.

- how does this interact with the per-user daemon operation?

- ideally, gconf lock files would go with the temporary data and gconf
data with the permanent, though i don't know enough about gconf to
know if this is easy or even plausible.

any thoughts?  is this feasible / wanted / worth putting some effort
into?  are there complications i haven't considered?

-damon