On Wed, 2012-04-11 at 14:39 +0200, David Henningsson wrote: > On 04/11/2012 02:16 PM, Tanu Kaskinen wrote: > > On Tue, 2012-04-10 at 17:02 +0300, Tanu Kaskinen wrote: > >> Back in December I sent a patch series that implemented > >> configurable port properties: > >> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/12070 > >> > >> David Henningsson pointed out that having a separate > >> "Property List" section would be nicer syntax than having > >> just one option in the "General" section containing all > >> properties. I implemented that then: > >> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/12075 > >> > >> This time David suggested that "Properties" would be > >> a better section name than "Property List". > > Or maybe even better, make it configurable... :-) but that can maybe > come later, if there is ever a need. Yes, but I think it's quite unlikely that there would ever be need for that. "Properties" is such an awesome section name :) > >> Also, Maarten > >> Bosmans suggested further refactoring in the configuration > >> parsing code: the parse callbacks could also take the parser > >> state struct as a parameter, instead of passing all > >> the state information in separate parameters. This third > >> patch set implements those suggestions. > > > > Sorry, I was stupid and sent the patches without proper testing. The > > second patch makes Pulseaudio crash, so please ignore this submission. > > Also, while testing today and trying to read the port proplists with > > pactl, I realized that it would be very nice to have the port proplists > > included in the client protocol, and to print them in the pactl list > > output. I'll implement those features and resubmit these patches. > > The port proplist is already in v26 of the protocol. That's correct, I just noticed that also myself. It's included only for cards, however. I'll add it also to sink and source ports. > In general, I totally agree with the parser_state refactoring (struct is > better than a lot of parameters), but I wonder if we're so close to a > release - and the patches are quite big - that it maybe should be > deferred to 3.0? I don't have a very strong opinion on the matter. This is definitely for 3.0. I just don't want to sit on patches that are "ready". -- Tanu
