On Tue, Aug 07, 2001, Nick Lamb <njl98r@xxxxxxxxxxxxxxx> wrote: > IMHO you'd be better off just using: > > wad://home/raph/slimy.wad/p/alien.foo > > 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): http://www.microsoft.com/favicon.ico/16x16x4 ftp://metalab.unc.edu/pub/Linux/games/doom/doomv18.wad.gz/S/S_SKY1 /home/bofh/lart.tiff/page3
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: http://www.microsoft.com/favicon.ico#16x16x4 ftp://metalab.unc.edu/pub/Linux/games/doom/doomv18.wad.gz#S/S_SKY1 /home/bofh/lart.tiff#page3
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 <sven@xxxxxxxx> 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.
-Raphael
