On 22 jun 2010, at 08:04, Silvia Pfeiffer wrote: >> Currently, we indeed represent multiple tracks through one track param, both >> at server-side through query parameters and at client-side (i.e, the Media >> Fragments Player) through URI fragments. Note that representing multiple >> tracks through multiple track params introduces difficulties when we use >> query parameters, since the server will only interpret the first occurrence >> of a track param ... So I would vote for combining multiple tracks into one >> track param. > > Yes, I prefer that, too. It's also how it is in the HTTP headers and > makes things more compact and easier to parse. Now I am confused. My personal preference is also for multiple track names specified in a single track= parameter (and similar for during http protocol handling), but what I remember is that this was considered to be impossible (or difficult?), because of the lack of a decent grammatical construct for the separator. This was the whole discussion about when percent-escaping is done. As far as I remember things, this is why we opted for multiple track= parameters (even though this has the disadvantage of treating the track= parameter differently than the spatial and temporal parameters. Does anyone remember why we ended up with multiple track= parameters? -- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma GoldmanReceived on Tuesday, 22 June 2010 19:39:38 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:39 GMT