Posted by pietblok
on September 3, 2007 at 7:43 AM PDT
Some protocols for reading files rely on a document URI or URL when links in the file refer to relative URL's (like in many XML files). FileContents gives me only an InputStream, not a base URL.
The only thing I can think of to work around this problem is to provide some dummy URL (syntactically valid, but non existing) and hoping that the user chooses a file that does not contain relative references.
I was thinking of implementing my own URL protocol, but then, the only thing I can do in such an implementation is ask the user something like: "You previously choose a file named so and so. This file refers to some other file with this relative path. Please be so kind to choose this file for me". Not very user friendly.
Then I thought, why does FileContents not offer me a URL with a specific FileContents protocol (like the jar protocol), something like:
where filecontents-id refers to some internal identifier of the codebase FileContents.
The protocol handler of course must be tightly coupled with the FileContents implementation for security reasons. And it should ask the user if it is permitted to read the linked file (with a do not ask again check box).
This all being a lot of whisfull thinking.
My question: How do you solve this problem of relative linking?