Re: Processing requirements

On Sun, 10 Jan 2010 00:37:33 +0100, Jack Jansen <Jack.Jansen@cwi.nl> wrote:

>
> 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.

Note that by mix-and-match I meant simply mixing MF with something else,  
not just when they collide. Certainly an extension that collides with MF  
is worse than one that doesn't, but I think the latter is a bit  
problematic too in that it will in practice limit what names we can use in  
MF2 depending on what server implementations have become popular and their  
extensions.

> 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.

The prefix idea is a good one, but how about forcing the extensions to use  
it instead of MF, just like with CSS: -foo-name. This would be applicable  
to the fragment syntax too if UAs want to experiment, so you might see  
e.g. #t=20&-o-aspect=4:3 or something if Opera wants to be able to force  
the aspect ratio like this (we don't, it's just an example).

> 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.

I agree, I'd rather we not meddle with this, but if want to specify how to  
express MF in the query component (as opposed to just passively accepting  
that some implementations might support it) then we have to take into  
account the fact that the query component already has different parsing  
rules on different servers and that resources already exist that use the  
query component with names that may or may not collide with MF. Given a  
way to resolve such conflicts with prefixes is a fair enough solution in  
my opinion.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Monday, 11 January 2010 08:54:28 UTC