On Wed, Aug 08 2001, Nick Lamb wrote: > On Wed, Aug 08, 2001 at 01:54:53PM +0200, Raphael Quinet wrote: >> 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. > > That creates an equivalent problem to your original one. If you really > want gimp-devel to believe that you routinely load remote WAD files > from HTTP then I'm going to have to ask that they also believe that users > routinely create files called foo.wad#Q/S_SKY1
Well, in that case they would be creating a directory called foo.wad#Q containing a file called S_SKY1. Not very likely, but possible...
> <serious> > > Further, this problem is actually blocking your original proposal for > users being able to save their Doom textures back into the WAD. With > the wad:// URI scheme and associated interactive browser we can make > this work seamlessly but with your #fragment solution it becomes > harder to make it work at all without second guessing the user. > > </serious>
The problem with the wad:// URI scheme is that it uses "wad:" as a protocol identifier (this should only be used for transport protocols, not for file formats) and it forgets about the original one. If I continue to believe that some users routinely load images or wad files via HTTP, I could as well believe that some of them have access to a web server that supports the HTTP PUT method. In that case, saving the file as "http://some.host/wadfiles/foo.wad#S/S_SKY1"; shoud work (saving the new chunk of the file could be done by re-loading the full file, merging the new chunk, then saving the whole thing back to the server with a PUT request). If the "http:" prefix is replaced by "wad:" then there is no chance to save the file back to the server. This example looks a bit ridiculous if we talk about WAD files because these are usually rather big but this becomes more realistic if we consider icon files, especially the popular favicon.ico.
Note: I hope that it will soon be possible to use the Gimp to load and save files over HTTP as easily as it can be done for the local file system. I already use HTTP frequently within the Gimp for loading images, because it is much faster to copy the URL of an image that I am viewing in Netscape than to save the file to disk, then find it and load it in the Gimp.
I think that using the standard "#" for separating the URI from the fragment identifier is the best solution for all images that are loaded using a full URI. However, as you mention this is not ideal when dealing with files on the local file system because "#" is a valid character that can be used in the names of files and directories.
So even if it is extremely unlikely, it would be possible to have a file named "foo.wad" containing an image called "S/S_SKY1", together with a directory named "foo.wad#S" containing a file "S_SKY1". This is not a real problem when loading an image, because the Gimp would always try to load the full path first and it would get the file "S_SKY1". If the user wants to get the one inside "foo.wad", it would still be possible to load "foo.wad" directly, then select the appropriate image using the interface provided by the WAD plug-in. Another solution for the user would be to select the file type explicitely (WAD file). The Gimp would then Do The Right Thing.
This could be a problem when saving the file, but this can be solved in the same way as above: use the full path by default if the file already exists, or use the corresponding archive format and assume that the part following the "#" is the fragment identifier if the user has selected a multi-image file format explicitely. If neither of this is true (for example if the user wants to create a new file in a new directory and does not specify a file format when saving), then it's guessing time... but it is reasonable to assume that a "#" preceded by a known file extension used for multi-image files is much more likely to represent something like "file.ext#fragment/blah" where "file.ext" is a file than "dir.ext#extra/file" where "dir.ext#extra" is a directory. Hmmm... This is a bit confusing, but hopefully you understand what I mean. I think that it would also follow the principle of least surprise for the users, so it would be easy for the users to work with this.
> Raph, don't let me stop you if you're sure this is the Right Thing, > but maybe you should consider bolting Doom itself into Gimp, so that > we can just use weapons/ tools to retexture things from inside the > game and see the results instantly? :)
Errr... This will be for a future release... :-)
Note that even if the examples are using Doom WAD files, the same thing could/should also be done for .ICO files containing multiple icons, multi-page TIFF files, etc. So this is not only for games.
-Raphael
