On Wed, 2011-02-16 at 12:33 +0000, Colin Guthrie wrote:
> 'Twas brillig, and Arun Raghavan at 16/02/11 04:42 did gyre and gimble:
> > On Tue, 2011-02-15 at 12:33 -0600, pl bossart wrote:
> >>> Please review/comment. Once we have some consensus, I'll send in patches
> >>> to actually get this done.
> > [...]
> >> - The receiver may support the same format at different sampling
> >> frequencies (eg MPEG at 32, 44.1 and 48kHz but not any other for BT).
> >> We will need to list explicitly which sampling frequencies are
> >> supported for each format.
> >
> > This one will probably be somewhat contentious. I was going to put this
> > information in the format_info structure's proplist so clients can read
> > and match as they please. There is one stumbling block here in that
> > proplists do not allow list or range types.
> >
> > We can either support these by abusing the proplists a bit (for ranges
> > have a "prop.min" and "prop.max", for lists have "prop.num_elements",
> > "prop.elem_0", "prop.elem_1", etc.), using simple strings (the way
> > GstCaps are done) or add first-class list and range types. Listed in
> > increasing order of effort.
> >
> > IMO the first is too hacky. The second is quite flexible, but
> > potentially too generic? The third is the most disruptive, but also most
> > exactly suited to what we need.
> >
> > I'm leaning towards the second (string representation like "(type) [min,
> > max]" for range and "(type) { val1, val2, val3 }" for list). In the
> > current context, the type might be implicit in the key, but since this
> > literally becomes part of the API, I'd like to plan ahead.
> >
> > Thoughts?
>
> Random suggestion:
> 1. The range thing seems simple enough the prop.min and prop.max seems
> like an easy enough thing to list and support (perhaps even with a
> wrapper function if it saves a bit of sanity checking).
>
> 2. The lists are slightly harder, so how about we just support JSON
> style syntax here for simple array storage? i.e. "['val1','val2','val\'s
> beyond']" ? Again a wrapper function or two can help create/decode
> these? Using a format like JSON should be pretty simple and we could
> easily enough push out the whole proplist as a single JSON encoded thing
> at some point in the future if needed too.
We really should decide on what we need first, I guess :)
I assume that for a given property, the data type is implicitly
understood (this is how things work now).
The other thing to worry about is whether a given property should be
expected to only be either single-valued, a range or a list. This might
not be true - for example when querying a sink, you might get the
supported sample rates as a list, but when connecting, sample rate is
single-valued (we might not use properties to set the sample rate, but
as a generic data structure, I hope you see my point).
>From the API perspective, perhaps we could add an enum to represent the
type (single-valued, multi-valued, range), and then have an API to query
this (like pa_proplist_get_type(proplist, key)) that clients would use
if multiple possibilities exist. We can then have API for each type.
Implementation wise, I think it's nicer to just have one key and do some
string parsing for the range case as well.
One thing to note here is that we cannot support lists of strings since,
aiui, JSON requires that strings be enclosed in quotes and we do not
currently do this for single-valued strings. The json.org site is down,
so if I'm wrong, I blame Wikipedia. :)
-- Arun
