On Wed, Aug 08, 2001 at 01:54:53PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote:
> No, using a special protocol in the URI will not work, because it

then how about appendign a space and then attr=value pairs? spaces are not
valid in uris. other options incldue { } or other characters not allowed
in uris. or 8 bit characters (still not allowed in uris etc..)

> 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).

the question is, could it hurt us doing things like this:

   <http://www.microsoft.com/favicon.ico subimage=16x16x4>

of course, there is a user interface issue: users like to enter broken
uris (usually a cut&paste issue).

> 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

wenn, if we insist on uris in the api this is not a problem as # must be
escaped. but it's bad because of other reasons: # makes sense for http
uris (e.g. xpointers!) already, so we would have this:




both of which are "wrong".

> anything after the "#" before sending the request, and then interpret

the problem is that "#" is not nestable. and the file system layer might
want to use it itself.

      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [EMAIL PROTECTED]      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
Gimp-developer mailing list

Reply via email to