Re: Processing requirements

On 5 jan 2010, at 22:10, Philip Jägenstedt wrote:

>>> Say someone already has a resource http://example.com/getvideo?id=42 (where
>>> 42 might be a database row id or something). id here doesn't refer to the id
>>> in MF. Is it possible to add MF syntax like 't=5' on top of this? It would
>>> be valid syntax but id would be ambiguous. Should it be valid to mix other
>>> pre-existing names that don't collide, like
>>> http://example.com/getvideo?foo=42&t=5 ? It seems we are making it very
>>> difficult to migrate any URLs that already use the query component to use
>>> MF. This isn't really an issue in the fragment case as there's not really a
>>> lot (any?) existing use of the URI fragment that we could trample on.
>> 
>> Yeah, I think that's the advantage. The main query strings ppl are
>> after are the ones we are defining here. Then there are less important
>> ones, such as format="jpg" asking for a time offset to be returned as
>> a thumbnail etc. YouTube has a gazillion of them and anyone wanting to
>> implement a good media server is highly adviced to check out YouTube's
>> query (or rather: fragment) parameters to see what is possible.
> 
> If we not only allow but even expect server developers to mix and match freely in the query string, is it possible to have any meaningful conformance requirements for them? At least the following break:
> 
> * We can't define how to extract a name/value list from the query string, because the server might already have other requirements e.g. with regards to how to treat '+', which character encoding to assume when decoding % encoding or already use the same names as MF for something else.
> 
> * We can't define how to map a name/value list into a set of dimensions, because only the server knows which names were actually intended for MF and which just happen to collide.

I think it is a bad idea to allow servers to freely mix-and-match, for the reasons you state. It is absolutely fine for a server to extend the set of name/value pairs, and it is even fine for a server not to implement one of the name/value pairs (as long as it returns the correct error or resource as stated by the MF spec). But if a server allows, say, "id" but interprets it wholly different then this server is not MF-compliant.

If we think there's a real danger of name collisions we could go the whole way and prefix our names with mf- or something, but then you get ugly http://example.com/video.ogg?mf-t=3 urls. My preference is that for the 1.0 spec we just cross our fingers, and it if turns out we are wrong we fix things with non-colliding names in the next version of the spec.

I think the "partially compliant" idea doesn't fly, or at least it has serious drawbacks. For example, if the MF url is created by a program it must know that it is interpreted correctly. Take a SMIL player that has to fetch the media for <smil:video src="http://www.example.com/video.ogg" clipBegin="10s" clipEnd="20s"/>. If the server advertises that it supports MF the SMIL player must have the freedom to simply send the URL http://www.example.com/video.ogg?t=10-20 to the server and get the expected data back.
--
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 Saturday, 9 January 2010 23:38:30 UTC