On 09 Aug 2001 00:19:41 +0200, [EMAIL PROTECTED] 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.


_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to