[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-filesystem-dev
Subject:    Re: [Filesystem-dev] file:/// url issue revisited
From:       dhedbor () real ! com
Date:       2005-01-21 18:24:29
Message-ID: 87r7key71e.fsf () asgard ! prognet ! com
[Download RAW message or body]

Comments below...

Liam Murray <liamm@real.com> writes:

> Hmmm,
>
> My understanding is that splay adds "file://" in the third case. So if
> "file://test.mp3" on the command line resulted in looking for
> "/test.mp3", so would "test.mp3". I'm confused. I would think that
> therefore splay would have looked for "test.mp3" in "/" all along.

No, m_pFilename is "test.mp3" in all the cases I mentioned because
currently both file:/// and file:// are parsed to the same filename
(i.e no leading slash for either case).

> Or does splay pass the url (without the file prefix) directly on to
> IHXPlayer? My recollections is that IHXPlayer::OpenURL always requires
> a scheme prefix so I would think if this were the case that it would
> fail.

splay adds file:/// and file:// for the two cases. However due to the
change to the URL parsing, these two are equivalent. 

> At any rate, to deal with this the UI can handle a non-absolute path
> filename by combining a file:/// + "./" + {relative path} so we get
>
> file:///./test.mp3

Yes, this could be one solution for the command line issue. However an
old ram file might very well have file:// URL's to indicate relative
paths, and those would still break.

> Note we assume that the file is relative to cwd. That makes sense on
> the command line. In certain cases (in a ram or smil) it won't make
> sense to assume a relative path is a file relative to cwd. Smil
> handles this well because it supports relative/absolute url usages as
> described in the rfc. The ram renderer has its own peculiar logic
> based on the number of slashes it sees. As I recall in one case it
> assumes the file is relative to the location of the smil file, in
> another relative to the location of the smil file that may reference
> the ram file.

> Liam
>
> At 03:54 PM 1/20/2005, dhedbor@real.com wrote:
>
>>I have one issue with the solution you have provided - it will break
>>implicit relative URL's. I.e:
>>
>>splay file://test.mp3
>>splay file:///test.mp3
>>splay test.mp3
>>splay /test.mp3
>>
>>All the above will look for the file "/test.mp3" since the filename in
>>all examples end up being "test.mp3". You would have to use a path to
>>specify relative URLs, i.e:
>>
>>splay ./test.mp3
>>
>>This is the direct opposite of the issue I brought up and although
>>it's probably less severe, it's still a change that needs to be
>>considered.
>>
>>
>>Liam Murray <liamm@real.com> writes:
>>
>> > At 01:43 PM 1/19/2005, Rob Lanphier wrote:
>> >>Hi Liam,
>> >>
>> >>Firefox, Mozilla, xmms and RealPlayer 10 for Linux treat
>> >>file:///some/path as an absolute reference to /some/path on the local
>> >>machine.  There is ample precedent and little ambiguity in current
>> >>practice, even if the spec is unclear.
>> >
>> > I probably wasn't clear.
>> >
>> > I'm not arguing against interpreting file:///some/path as relative to
>> > root on Unix. I think it should be interpreted that way.. I'm just
>> > saying that when we parse out the <path> component of the url (in
>> > HXURLRep) we get path = "some/path". If there are four slashes we get
>> > "/some/path". (If there are two paths we get authority = some and path
>> > = "path".) That is, we interpret the third slash as the delimiter
>> > between <auth> and <path> in the generic uri syntax per rfc
>> > 2396. (Actually, that rfc seems to suggest that <path> includes that
>> > delimiter, while the rfc that mentions the file scheme specifically
>> > suggests that it is not.)
>> >
>> > HXUrlRep therefore lets the user of the parser decide whether or not
>> > it wants to treat
>> >
>> > file:///some/path
>> >
>> > and
>> >
>> > file:////some/path
>> >
>> > as equivalent.
>> >
>> > I was simply saying that how the path part is interpreted is up to the
>> > app and there is nothing in the URL-related rfc's that say we have to
>> > interpret them one way or another. I think it is good that we base the
>> > interpretation on expected behavior based on precedent and
>> > os-convention. Therefore on Unix "file:///some/path" results in the
>> > app looking for "/some/path". On Windows it is probably not a good
>> > thing to  interpret "some/path" as relative to '/' since that doesn't
>> > make so much sense. (Some apps seem to interpret this as "//some/path"
>> > where 'some' is a network share.) On Symbian the os often tries to
>> > hide the actual filesystem from the user, so theoretically an app
>> > could interpret paths in a file url as being rooted relative to some
>> > user-exposed (or perhaps app-associated) folder that is not at the
>> > actual file system root.
>> >
>> > Liam
>> >
>> >>Having an API that treats file:///some/path as a relative path is
>> >>horribly confusing.  If it's really necessary to have some way of
>> >>expressing relative URLs with a protocol specifier, my recommendation is
>> >>that we invent a new one (e.g. "filerel:some/path") rather than
>> >>overloading a widely-used existing scheme.
>> >
>> > There is a relative url format, which is essentially a path. In this
>> > case it would be
>> >
>> > some/path
>> >
>> > You just need to have a context (an xml document for example) where an
>> > absolute base url (with scheme) is established.
>> >
>> >>Rob
>> >>
>> >>On Wed, 2005-01-19 at 12:15 -0800, Liam Murray wrote:
>> >> > I think the best way for our url parser (CHXURL/HXURLRep)
>> >> interpret these is:
>> >> >
>> >> > file:///some/path
>> >> >
>> >> > yields path = "some/path"
>> >> >
>> >> > and
>> >> >
>> >> > file:////some/path
>> >> >
>> >> > yields path = "/some/path".
>> >> >
>> >> > At the very least this lets you unambiguously encode the paths within a
>> >> > file url and distinguish between the two path values in case doing so is
>> >> > meaningful to the app.
>> >> >
>> >> > Then the app can decide how to interpret these.
>> >> >
>> >> > The application can decide in the first case whether "some/path" is
>> >> > relative to "/" or "./".
>> >> >
>> >> > In the second case, the application can decide what root is, the root of
>> >> > the local filesystem or some virtual root. I don't think any
>> rfc specifies
>> >> > that the paths in a file url have to be interpreted by all apps as being
>> >> > relative to the local filesystem. It normally makes sense for the app to
>> >> > interpret the file as relative to the filesystem root so this is just a
>> >> > technical point.
>> >> >
>> >> > As you point out it is common practice, particularly on Unix, for
>> >> > "some/path" to be interpreted relative to the local filesystem root.
>> >> > Interpreting  "some/path" relative to "." often doesn't really
>> make sense
>> >> > anyway, particularly if you launch from the ui
>> launcher/explorer where it
>> >> > is not always clear/obvious what "." is. If you are running the
>> >> player from
>> >> > the command line and you want to play a file in your current
>> >> directoy, then
>> >> > you can always type
>> >> >
>> >> > player file:///./my/local/file.rm
>> >> >
>> >> > to explicitly "mean relative to cwd".
>> >> >
>> >> > On windows we could interpret "some/path" as relative to "c:\"
>> but that is
>> >> > not common practice. (Internet Explorer doesn't appear to do this.) On
>> >> > windows I think common practice is to just pass "some/path" on
>> to fopen or
>> >> > whatever api is used to open the file.
>> >> >
>> >> > I agree that the way the mini filesystem was interpreting the
>> URL on Unix,
>> >> > i.e., relative to ".", was not good. If on Unix and similar
>> >> filesystems the
>> >> > full filesystem plugin is failing to find
>> >> >
>> >> > file:///some/path
>> >> >
>> >> > relative to root then I think it should be fixed in the
>> filesystem plugin
>> >> > so it looks for "some/path" relative to root.
>> >> >
>> >> > Liam
>> >> >
>> >> > At 11:13 AM 1/19/2005, dhedbor@real.com wrote:
>> >> > >Some time ago there was a discussion about the URL syntax of file:
>> >> > >URL's. Specifically in the mini filesystem, file:///some/path URL's
>> >> > >didn't work but were considered relative to the current directory of
>> >> > >the application, while the full local filesystem handled these URL's
>> >> > >as most would expect, i.e as a path relative to the root of the
>> >> > >filesystem.
>> >> > >
>> >> > >Today, with a current HEAD build, the behavior of the full local
>> >> > >filesystem as well. I have also checked and verified that a URL in a
>> >> > >.ram file will result in the same behavior.
>> >> > >
>> >> > > >From the previous discussion, it's clear that the
>> specifications don't
>> >> > >clearly explain how this should work (on a UNIX platform or any other
>> >> > >platform). Given that this is a gray area, I think it is prudent to
>> >> > >adhere to the de-facto standard, which is that an absolute file URL
>> >> > >uses the "file:///some/path" syntax. Requiring the use of
>> >> > >"file:////some/path" will if nothing else be backwards
>> >> > >incompatible. To point this out, even splay from HEAD breaks due to
>> >> > >this syntax as shown here:
>> >> > >
>> >> > >   # ./splay /home/dhedbor/test.mp3
>> >> > >   Simpleplayer is looking for the client core at ./clntcore.so
>> >> > >   Common DLL path DT_Common=.
>> >> > >   Plugin path DT_Plugins=.
>> >> > >   Codec path DT_Codecs=.
>> >> > >   Can't open file: /home/dhedbor/.helix/HelixShared_0_0.
>> >> > >   opening file:///home/dhedbor/test.mp3 on player 0
>> >> > >   Report(3, -2147221496, "file:///home/dhedbor/test.mp3", 0, "(NULL)",
>> >> > >                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> > >   "Can't convert error code 0x80040008 - please find corresponding HXR
>> >> > >   code in common/include/hxresult.h")
>> >> > >
>> >> > >This is a situation where there is no 100% clear interpretation of the
>> >> > >standard, but one where there is a very strong precedent in past and
>> >> > >current products, including those released by RealNetworks. I cannot
>> >> > >remember any product which required you to use the format
>> >> > >"file:////some/file" to access a file on the local file system
>> >> > >relative to the root. However there are countless of examples where
>> >> > >"file:///some/file" URL's are used. .
>> >> > >
>> >> > >
>> >> > >--
>> >> > >David Hedbor, Software Development Engineer - RealNetworks
>> >> > >Helix Community: http://helixcommunity.org
>> >> > >
>> >> > >
>> >> > >_______________________________________________
>> >> > >Filesystem-dev mailing list
>> >> > >Filesystem-dev@helixcommunity.org
>> >> > >http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Filesystem-dev mailing list
>> >> > Filesystem-dev@helixcommunity.org
>> >> > http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
>> >>--
>> >>Rob Lanphier, Development Support Manager - RealNetworks
>> >>Helix Community: http://helixcommunity.org
>> >>Development Support:
>> >>http://www.realnetworks.com/products/support/devsupport
>>
>>--
>>David Hedbor, Software Development Engineer - RealNetworks
>>Helix Community: http://helixcommunity.org

-- 
David Hedbor, Software Development Engineer - RealNetworks
Helix Community: http://helixcommunity.org



[prev in list] [next in list] [prev in thread] [next in thread]