[vlc-devel] mrl & uri

Vicente Jiménez googuy at gmail.com
Sun Jun 28 19:56:16 CEST 2009


+1
for sticking with RFC3986 if it's possible and doesn't involve a lot of work.

I would prefer the form:
file+avformat:// to keep the demux specifier
because:
 * it's seems more easy to adapt.
 * For people familiar with the MRL form, it's more similar.
 * and lastly, because I'm afraid that the option notation could
interfere with addresses that needs the fragment to identify a
particular resourse.


Cheers
vicente

On Fri, Jun 26, 2009 at 4:54 PM, Rafaël Carré<rafael.carre at gmail.com> wrote:
> On Fri, 26 Jun 2009 16:11:34 +0200
> Rémi Denis-Courmont <remi at remlab.net> wrote:
>
>>
>> On Fri, 26 Jun 2009 15:44:29 +0200, Rafaël Carré
>> <rafael.carre at gmail.com> wrote:
>> > IMO we should just stop using "mrls" but URIs (explanation at the
>> > end)
>>
>> There are no URI schemes for discs, DVB, radios, RTP, etc, that I
>> know. So err... we are kind of bound to use a superset of URIs. I
>> definitely agree that we should accept URLs, and use them when
>> possible, but I am afraid we are bound to MRLs as a *superset* of
>> URLs.
>
> A superset with a valid syntax.
>
> If a bit of work is required to adhere to the syntax described in
> RFC3986 I am willing to do it.
>
>> > Use cases of MRLs :
>> >
>> > - access/demux://blabla
>> >
>> >     The demux should be specified otherwise since schemes (the part
>> >     before ":") can not contain "/".
>> >     With input_item_AddOption() for example.
>>
>> Unfortunately, it seems that --demux is inherited, in case the input
>> item gets children items, which is typically inappropriate. IMHO, the
>> fact that the slash violates the URI grammar is a non-issue, so long
>> as it does not create any ambiguity. If I'm not mistaken, the scheme
>> always ends with a colon, so there should be no parsing ambiguity. I
>> must say, I fail to see what problem you are trying to solve by
>> forbidding the VLC demux specifier.
>
> No problem within VLC, but what when VLC communicates with the external
> world ? (xspf playlists, DBus interface, ..)
>
> This is why I wanted to stick with the syntax, because if we use
> unregistered schemes, other applications than vlc would not choke on
> the validity but just ignore them.
>
> + . and - are valid in schemes, so we could for example use
>  file+avformat:// to keep the demux specifier.
>
>> > - access://blabla@options (for example cdda:///dev/cdrom@53 , or
>> > vcd)
>> >
>> > We should use something more correct, but it's not very important
>> > since cdda: is not a registered scheme
>> > (http://en.wikipedia.org/wiki/URI_scheme for the list)
>> >
>> > Here is an example from rfc3986:
>> >
>> >          foo://example.com:8042/over/there?name=ferret#nose
>> >          \_/   \______________/\_________/ \_________/ \__/
>> >           |           |            |            |        |
>> >        scheme     authority       path        query   fragment
>> >
>> > cdda:///dev/cdrom#53 looks fine to me.
>>
>> This might be a good idea.
>>
>> > If you know of other cases for "MRLs" please state so.
>>
>> SSM with UDP and RTP remain problematic; we have two address & port
>> tuples to fit in the location.
>
> Thanks, I'll look into these.
>
> --
> Rafaël Carré
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
>
>



More information about the vlc-devel mailing list