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

[David Henningsson]

On 2014-09-18 02:18, Glenn Golden wrote:
> 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).

When all this is done, you'll write up a nice wiki page or blog post 
explaining it all, right? :-)

> 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(),

...then that means, move on to step 2) in the list above.

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.

There are two lists here, let us not confuse them. We have the 1-9 list 
which I provided, and we have the server_list.

The server_list is a list of servers to try in order, so that if one 
fails, try the next one.

For step 1) to 4) in my 1-9 list, anything non-NULL will completely make 
up the entire server_list. You can even specify more than one server, 
just separate your servers with newlines, tabs or spaces and it will be 
two or more items in the server_list.

If all of 1) to 4) are NULL/unset, for step 5) to 9) in my 1-9 list, the 
server_list is additive. I e, all of step 5) to 9) will result in one or 
zero more items added to the server_list.

And when the server_list has been populated, all servers in the 
server_list will be tried, in order, until one succeeds.


E g, if you have a command line looking like this:

PULSE_SERVER="hostA hostB" pactl --server="hostC hostD"

...we will try hostC first, and if that fails, try hostD. hostA and 
hostB will not be tried, because step 1) is non-NULL.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic