Re: Generalising inlined images

Tony Sanders <sanders@bsdi.com>

Mail folder: WWW Talk Oct 93-present
Next message: Tony Sanders: "looking for: WWW based reservation system"
Previous message: Marc Andreessen: "slideshow-1.2 and xmosaic-2.pre4: minor problem"
Reply: Tony Sanders: "Re: Generalising inlined images "
Reply: Gisle.Aas@nr.no: "Re: Generalising inlined images"

X-Delivered: at request of secret on dxcern.cern.ch
Errors-To: sanders@bsdi.com
Message-id: <9310061941.AA04259@austin.BSDI.COM>
To: www-talk@nxoc01.cern.ch
Subject: Re: Generalising inlined images 
In-Reply-To: Kevin Altis's message of Wed, 06 Oct 93 11:42:12 -0800.
Errors-To: sanders@bsdi.com
Reply-To: sanders@bsdi.com
Organization: Berkeley Software Design, Inc.
Date: Wed, 06 Oct 1993 14:41:04 -0500
From: Tony Sanders <sanders@bsdi.com>

> of inclusion types. What I have in mind is to put the MIME types into the
> tag syntax so you might do <INC text/html="..."> or <INC image/gif="...">
> or <INC sound/wav> or <INC x-command/. This simplifies the syntax and at
Please don't do that.  Putting the type in the link is exactly where
we don't want that information.  The way this should work is:
    <EXTERN HREF="...">

Then the browser sends the request with the list of acceptable formats:
    GET ... HTTP/1.0
    Date: Sunday, 03-Oct-93 19:37:52 GMT
    Accept: text/plain; text/html; image/gif; image/x-xbitmap

Then the server responds:
    HTTP/1.0 200 Document follows
    MIME-version: 1.0
    Content-type: image/gif
    ...

Oh BTW.  While we are talking about this part of the protocol I just want
to remind everyone that something like <EXTERN HREF="..." ISMAP> is *NOT*
needed.  This information should be part of the returned object.  The
reason I made <IMG ISMAP> is because at that time we only had HTTP0 clients
and servers.  Since all the browsers will soon support HTTP/1.0 ISMAP is
depreciated in favor of server responses like this:
    HTTP/1.0 200 Document follows
    Public: GET HEAD SPACEJUMP
    MIME-version: 1.0
    Content-type: image/gif
    ...
The "Public: SPACEJUMP" is the trick (btw it might also be "Allowed: SPACEJUMP"
browsers must check in both locations).  This means that the current
document can be manipulated in the curious way we happen to support
spatial indexing (the same way as ISMAP currently where the browser
sends the offsets in a query).  All future extensions should be along
these lines.  If you need an object to have attributes don't put them
in HTML, return them with the object.  Remember those same objects
might be used by some other system than WWW in the future.

> the same time allows a lot more flexibility than we currently have. The
> biggest win comes when the client software has MIME to application mappings
It's the wrong approach.

> Inlined should always behave like characters, otherwise you can't do tiling
> and other important layout things.
Shame on you for mentioning "layout" :-)

> My other problem with <IMG SRC...> and <INC SRV...> is that they do
> different things depending on whether you're fetching via an HTTP server or
> a client. I don't have any easy answers right now, but I forsee major user
> confusion when people put together documents and test them locally, only to
> find out they don't work off a server because of access privs. relative
> pathing, etc. Any ideas?
I think hacking <INC> into the server is a bad idea.  I've mentioned this
before.  If you do that then you have really created a new type and it
should be filename.hacked-html  instead of filename.html to make it
clear that it's not HTML.  Then format negotiation would convert
text/x-hacked-html to text/html if required (and when browsers start
support <INC> They will just Accept: text/x-hacked-html).

--sanders