On Tue, Aug 07, 2001, Nick Lamb <[EMAIL PROTECTED]> wrote:
> IMHO you'd be better off just using:
> This can be handled today in Gimp 1.2, see url.c
> Non-interactive stuff would go exclusively through these URLs while the
> interactive user would also need an Open, and possible Save As...
> handler for the WAD file itself, which would simply be a browser or
> other UI for picking sub-directories and files.
No, using a special protocol in the URI will not work, because it
should still be possible to retrieve the file using any protocol such
as http: or ftp: (the only difference being that you only use a part
of it). For example, I would like to be able to load the following
images (the first two are based on existing URLs):
If we want to avoid 404 errors from the web servers, we could decide
to use "#" instead of "/" as a separator between the real file name
and the extra path to the image. I initially thought about this and
then rejected the idea later because local files can have a "#" in
their name, but this should not be a problem if the Gimp always starts
by trying to open the local file with the full path (if no protocol is
specified) and then tries a second time without the part that follows
the crosshatch sign.
So the examples above would become:
These URIs are in accordance with RFC 2396 which defines the URI
syntax. Chapter 4.1 of RFC 2396 specifies that the fragement
identifier (the part that follows the crosshatch) has to be
interpreted locally by the user agent after the retrieval of the
object, which is exactly what we want to do. The semantics of the
fragment identifier depend on the media type of the retrieved data,
which is also what we want to have.
On Tue, Aug 07, 2001, Sven Neumann <[EMAIL PROTECTED]> wrote:
> I don't think this is a good solution to your problem. It is in no
> way compatible with others programs or file system layers we might
> want to use in the future (like gnome-vfs for example).
If we follow the URI syntax described above, then I think that it
would work well. It is important that the virtual path contains the
real file name first, followed by the name of the image within this
file (the fragment identifier) so that we can use any protocol to
fetch the file.
Also, the semantics of the fragment identifier will be interpreted by
the plug-in after having retrieved the data, and this part cannot be
done by a file system layer. For example, a Doom WAD file contains
several types of images that are stored in different formats: the
floor and ceiling textures are 64x64 flat bitmaps, the wall patches
have a variable size with 1-bit transparency using RLE compression,
and so on. These images have no file extension or magic number that
could be used to get their type; their format depends only on their
position within the file: the path /F/... is used for floor textures
(stored between F_START and F_END) and implies that they are 64x64
flat bitmaps, while the images under /P/... are wall patches (stored
between P_START and P_END). Furthermore, all images are indexed and
implicitely refer to one or several indexed colormaps that are also
stored in the file, in a section called COLORMAP. Loading an image
from a WAD file must also load the colormap from the same file, or ask
the user for an appropriate colormap if the WAD file does not contain
one. All these semantics are specific to the manipulation of images
and are not suitable for integration in a file system layer.
> How is this
> supposed to work with non-local files? I don't think we want to
> wait for timeouts or interpret "File not found" error messages from
> a web|ftp|nfs|smb server while recursively stripping off stuff from
> our filename. If you want to support special filetypes that support
> filesystems inside files, please stay with standards and use a
> correct URI. As Nick already pointed out, the current API already
> supports this sort of stuff. If it needs additions or changes, we
> can of course change it now during the development cycle towards
> 1.4, but please let us find a reasonable solution.
If we use the "#" as a separator, that would solve the problem for
non-local files. RFC 2396 specifies that the user agent must strip
anything after the "#" before sending the request, and then interpret
it locally after having received the data. This means that we will
not get any timeouts or errors as long as the file exists, because the
Gimp will fetch the real file directly.
The local files are allowed to contain "#" as part of their name (if
they are specified without using a protocol prefix), and in this case
the strategy can be as I described previously: try first with the full
path, then try again after having removed whatever follows the last
"#", and repeat if there is more than one crosshatch in the path.
Gimp-developer mailing list