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
