Re: Processing requirements

On Mon, Jan 11, 2010 at 7:53 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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.

FAIK there aren't many media servers that use large amounts of
query/fragment schemes directly on the media files. Most do so on the
html pages (e.g. YouTube) and then relate that through to the video
that the page hosts. I don't think we will encounter many conflicts at
all, but rather ppl will start developing further schemes around our
MF schemes.


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

Interesting... we should discuss this idea of including a
"namespace"-style prefix. It makes it a bit lengthy and talkative, but
indeed easier to segment out from other name-value pairs.


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

I think we may be too much afraid of conflict with something that
doesn't exist yet.
Do you have examples of such conflicts?

Cheers,
Silvia.

Received on Monday, 11 January 2010 10:32:10 UTC