- From: Jack Jansen <Jack.Jansen@cwi.nl>
- Date: Tue, 22 Jun 2010 21:38:57 +0200
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Davy Van Deursen <davy.vandeursen@ugent.be>, raphael.troncy@eurecom.fr, Media Fragments Working Group WG <public-media-fragment@w3.org>
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 Goldman
Received on Tuesday, 22 June 2010 19:39:38 UTC