From: James Courtier-D. <Ja...@su...> - 2003-08-04 14:34:45
|
R. Bernstein wrote: > Okay, my mistake. I now see that something like cdda:///dev/cdrom > would an be illegal URI according to RFC2396. An extension to allow a > null "authority" though would permit this. > > BUT I would then suggest that if we are trying to follow the intent of > RFC2396 then we should try to follow the semantic interpretation as > closely as possible elsewhere as well. I personally don't like "I'll > pick from the spec when I feel like it and ignore it when I don't." > And those who make claims about using URI's for compatibility with the > world at large I think might want to pay close attention. > > So here we come to the fact that according to RFC2396 a fragment is > part of an entity or "abs_path", and the correct way to indicate this > is to precede the fragment with a #. Part of a CD-DA is a track. Part > of a VCD might be a track, entry, segment or LID. Part of a DVD is a > Title or Chapter (or whatever the DVD term is for "chapter"). So why > are we using a dot in the DVD plugin instead of #? > > I see that README.mrl uses # to delineate "stream_setup." That's > interesting but a bit unconventional, especially as "fragment" in the > sense that the RFC I think intends it to be, is much more appropriate > here. > This has been an ongoing problem for a long time now. The basic requirements for the mrl are: - 1) Input plugin name. 2) Device name for the input plugin to use. 3) Path to a file on the device. 4) Extra info for the input plugin. E.g. Title,Chapter to start on for playing a DVD. Maybe even info to get the dvd input plugin to only play a single VOBU or CELL then return. Other input plugins might want other information. 5) Extra config/directives. E.g. Force use of demuxer XYZ. The separator for (5) has in the past been %, : and currently #. If you are saying that # breaks the URL specification, then we need to replace it with a new method to implement (5). At the moment, each input plugin parses their own mrl, so there is a lot of code duplication there. I agree that we should provide a general api so that all input plugins can make a function call, and get returned specific information contained in the url, without having to parse the url directly. I don't have time to read RFC2396 right now, but maybe you can help. I think that a good plan would be to design a mrl that is in fact a url, and can be typed into any web browser, and will cause the web browser to call xine to handle the url. It should provide all functions of (1) to (5) above. Cheers James |