On 09 Aug 2001 00:19:41 +0200, pcg@xxxxxxxx wrote: > i assumed that gimp does have a file-system layer. or otherwise who > handles "paths" that really are urls for example? will every plug-in > implement it's own http:// parsing+fetching? no, i guess gimp handles > this, the file system layer within gimp, specifically. yes of course, but where's the difference in our problem here? > actually, it's dependent on the media type. and my concerns are not about > compatibility to current browsers or servers but in the future. it would > be bad if gimp became successfull and would create/user uri's internally > that cnanot be parsed by other programs (not even like: "oh, i can't parse > this"). 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. And not only does it not make a problem, the outcome is also the expected --- it loads the gif. GIMP on the other would maybe throw a warning for this uri, as there's no "subimage" of any sort in this gif. But that's just the added value we get because we decide what a fragment means for e.g. a wad file. As the "meaning" of a fragment is left to the media type (and the UA) there will just _never_ be a problem.
