> On Thu, Aug 09, 2001 at 12:42:33AM +0200, Jens Lautenbacher <jtl@xxxxxxxxxx> wrote:
>> yes of course, but where's the difference in our problem here?
>
> that the user agent is the gimp and might interpret fragment identifiers
> - at leats some underlying library might (and should) do that. my point
> is that we shouldn't just claim fragment identifiers as being "plug-in
> namespace".
The underlying library might (and should) handle different protocols, such as http:, ftp:, gopher:, email: and similar things. It should fetch the data, but it should not try to interpret it. This must be done by the user agent, in this case the Gimp, which delegates this to the appropriate plug-in depending on the type of the data. If some underlying library starts interpreting the fragment identifiers, then it violates the concept of URIs.
>> why should any future app that groks uris be unable to parse >> these??????? >> >> http://www.mozilla.org/images/mozilla-banner.gif#eeek >> >> when I type this in a web browser, there's no problem. There's in fact >> no problem with any app that correctly handles uris. > > Wrong. Some app might validly try to interpret eeek as something strange. > for example, some (bad) app might want a number there and might display > nothing. For some deifnition of correct this is correct, but... The > problem is that nobody knows how to interpret that "eeek" except the gimp, > and using a more verbose form at leats might give a clue that a subimage > with name is meant. [...] > Indeed. Why not do it as others and mark our namespace with something like > subimage(xxx) or gimp(xxx)?
I do not like the idea of using different namespaces such as #gimp() when loading chunks from an object, because this is adding an artificial separation where there does not need to be one. The namespace issue does not really exist, because I think that it is reasonable to assume that when a user types an URI in the Gimp, he expects it to be loaded by the Gimp or some of its plug-ins, not by a random application that would have to solve some namespace issues before knowing what to do with the data. Some applications might interpret the same URI differently, but I consider this to be a feature, not a bug. It is even an important feature.
Let's consider the example of WAD files again. Let's imagine that I have the Gimp with a WAD plug-in that is able to load and save the various types of images stored in the WAD files. Let's imagine that I also have another program, let's call it DEU (Doom Editing Utilities) that can edit the Doom levels but not the images; but since this is a generic WAD editor, it is at least able to re-organize the image chunks within the WAD files even if it cannot edit the image data. If I were using the namespace that you recommend, then I would have to use two different URIs to access the same things in the two programs: doom.wad#gimp(F/F1/FLOOR7_2) doom.wad#deu(F/F1/FLOOR7_2) I could not simply copy the URIs between the two programs and expect them to do whathever they can do with the same data. The URI should represent the (chunk of) data itself, not what you intend to do with it. Using a #subimage() prefix or something similar is not better, because a generic WAD editing tool should not have to know the type of the chunk (whether it is an image, a sound, a map or anything else) before being able to copy it, delete it, or move it to a different place. So the correct solution is to use a simple identifier for the data that depends only on the file format, not on the application that is expected to use it: doom.wad#F/F1/FLOOR7_2
Of course this means that the Gimp will not be able to load something like doom.wad#E1M1/LINEDEFS, which is part of the map data and does not contain any images. But in this case it would simply say that the user tried to load something that cannot be edited by the Gimp, just like it does when the user tells the Gimp to load an MP3 file or a compiled program.
-Raphael
