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?
