[pulseaudio-discuss] Pull request: Autospawn fix

[Tanu Kaskinen]

to, 2010-01-14 kello 14:56 +0100, Lennart Poettering kirjoitti:
> On Thu, 14.01.10 05:32, Tanu Kaskinen (tanuk at iki.fi) wrote:
> > Simpler, yes. More compatible, not much. The only cases that I can see
> > the proposed syntax would break are socket paths that
> > 
> >  * start with "[" (ie. they are relative paths, which don't make any
> > sense anyway, I think) or
> >  * contain commas.
> 
> ipv6 addresses are usually written with in [], so that the colons can
> be distuingished from the port seperator. Kinda sucks using colons in
> more than one context here?

Did you mean "using square brackets" instead of "using colons"? Colons
are used in multiple contexts anyway. If you meant square brackets, that
could be solved by separating the protocol tag in some other way, for
example:

example.com:native!4242,dbus!4343

> > I would like this to still work:
> > 
> > $ PULSE_SERVER=gurki pavucontrol
> 
> Yes, me too! 
> 
> So the way this should be interpreted is that the host name may be
> connected to by all protocols supported. That means via ipv4/native as
> well as ipv6/native (which is where we are currently at) in addition
> to ipv4/dbus as well as ipv6/dbus.
> 
> If you look at src/pulsecore/parseaddr.h you'll find
> pa_parsed_address_type_t. I'd like to extend that struct to:
> 
>     PA_PARSED_ADDRESS_NATIVE_UNIX,
>     PA_PARSED_ADDRESS_NATIVE_TCP4,
>     PA_PARSED_ADDRESS_NATIVE_TCP6,
>     PA_PARSED_ADDRESS_NATIVE_TCP_AUTO,
>     PA_PARSED_ADDRESS_DBUS_UNIX,
>     PA_PARSED_ADDRESS_DBUS_TCP4,
>     PA_PARSED_ADDRESS_DBUS_TCP6,
>     PA_PARSED_ADDRESS_DBUS_TCP_AUTO,
>     PA_PARSED_ADDRESS_TCP4,
>     PA_PARSED_ADDRESS_TCP6,
>     PA_PARSED_ADDRESS_DBUS_TCP_AUTO

I assume that last entry was supposed to be PA_PARSED_ADDRESS_TCP_AUTO.

> And writing PULSE_SERVER=gurki would be translated to
> PA_PARSED_ADDRESS_DBUS_TCP_AUTO which means that both the dbus and the
> native client would use that address. 

And I assume you meant PA_PARSED_ADDRESS_TCP_AUTO here also.

I think this is a fine solution. Just one question: would
"example.com:4242" be parsed as _NATIVE_TCP_AUTO, ie. ignored by D-Bus
clients? That would be a bit inconsistent, since usually strings without
any protocol prefix are parsed as _TCP_AUTO. Or should D-Bus clients
maybe try connecting to the default port on example.com? The latter
would be more compatible with existing configurations.

-- 
Tanu Kaskinen