[pulseaudio-discuss] [PATCH v2] core-util: Fail if XDG_RUNTIME_DIR belongs to someone else

[Glenn Golden]

David Henningsson <david.henningsson at canonical.com> [2014-09-17 10:47:09 +0200]:
> 
> 
> On 2014-09-17 02:38, Glenn Golden wrote:
> >David Henningsson <david.henningsson at canonical.com> [2014-09-16 08:02:50 +0200]:
> >>>
> >>>In 5b-c, is it possible that XDG_RUNTIME_DIR was intended?
> >>
> >>Yes, I meant XDG_RUNTIME_DIR. Sorry for the typo.
> >>
> >
> >No problem, just wanted to be sure, thanks for clarifying.
> >
> >But just to prove that no good deed goes unpunished, :) I'll pester you with
> >yet another question:
> >
> >Can you describe what pieces of information the pa_context_connect() API
> >function takes into account in determining (or guessing at) the server?
> >
> >The motivation for this question is that I'm wondering if this function is
> >the means by which a commandline option like "--server=XXXX" is handled
> >(e.g., by the caller providing "XXXX" to the function as a potential
> >candidate server, to be decided upon in addition to other pieces of info...) ?
> 
> If you give a "--server" argument to pactl, pactl passes that argument
> unchanged when it calls pa_context_connect(), hence the command line
> argument falls under point 1) in my list, for pactl.
> 
> Other applications might do things differently, e g by having a dialog box
> where you can configure the server name, and some are probably always
> passing NULL out of simplicity or laziness. Does that answer your question?
> 
> 

It answers the original one, thanks.  Unfortunately (for you :) ) it brings up
yet another one (or actually, two related questions). 

Background: Here's the first portion of the list you supplied earlier after
looking thru the code (which, btw, I greatly appreciate, thanks):

  1) Specified server(s) in the call to the pa_context_connect().
  2) Specified server(s) in PULSE_SERVER
  3) Specified server(s) in X11 property PULSE_SERVER
  4) Specified server(s) as in client.conf (the "default-server" key)

First question: If the caller does supply NULL as the 'server' parm to
pa_context_connect(), the doc for that function indicates that it will attempt
to connect to the default server. But if so, then it effectively short-circuits
the above sequence, first trying default-server, then PULSE_SERVER envar,
then PULSE_SERVER X11 prop.  Is that right?

Second question (partly related to above): I want to make sure I understand
how the difference between the following two situations is handled:

    * A given server specification (e.g. PULSE_SERVER) is not set.
    * A given server specification is set, but attempting to connect to that
      server leads to a connect error.

So, given the NULL short-circuit effect (if I'm even right about that) here's
my guess as to what I think happens. Let me know if this is right, or if not,
please correct:

    if (server is explicitly specified in pa_context_connect())
    {
	Try that explicly specified server. On failure, whine & die;

	if (envar PULSE_SERVER is set)
	{
	    Try that server. On failure, whine & die;
	}

	if (X11 prop PULSE_SERVER is set)
	{
	    Try that server. On failure, whine & die;
	}

	if ('default-server' is set) 
	{
	    Try that server. On failure, whine & die;
	}
    }

   else		// 'server' parm is NULL
   {
	if ('default-server' is set) 
	{
	    Try that server. On failure, whine & die;
	}

	if (envar PULSE_SERVER is set)
	{
	    Try that server. On failure, whine & die;
	}

	if (X11 prop PULSE_SERVER is set)
	{
	    Try that server. On failure, whine & die;
	}
   }

In the 'else' clause, there's effectively no #4 (default-server) because
the default-server was already tried first as a consequence of the NULL
'server' parameter supplied to pa_context_connect(), and if that didn't
work, it would have already died.

Is this right?