Re: Server-side data conversion and Internet bandwidth (was: Re: Multi column

Terje Norderhaug (Norderhaug.CHI@xerox.com)
Mon, 26 Jun 1995 15:13:01 -0800


Message-Id: <ac14ec3e0802100439d4@[130.191.70.106]>
Date: Mon, 26 Jun 1995 15:13:01 -0800
To: jw@scitsc.wlv.ac.uk (Jon Wallis), www-html@www10.w3.org
From: Norderhaug.CHI@xerox.com (Terje Norderhaug)
Subject: Re: Server-side data conversion and Internet bandwidth (was: Re: Multi column

At 10:52 PM 6/25/95, Jon Wallis wrote:
>>At 02:29a 06/25/95, Philippe-Andre Prindeville wrote:
>>
>>>Just here:  image scaling (ie. fitting an image into a
>>>640x400 rectangle), depth reduction (taking a 24bit GIF file
>>>and rendering it in 1bit deep B&W on a notebook), etc.  should
>>>be done *SERVER-SIDE*.

>I think most of the action *should* be server-side (i.e., only send what the
>browser wants or can handle), but this requires a start-up dialog between
>browser and server to establish what the browser *can* handle (not too
>difficult to establish).

It is already partly in place, as the browser will send what formats it support.

>Also there seems to be too much emphasis on
>"in-line" capabilities - the fact that you can spawn "helper-apps" was/is a
>real strength of Web browsers - extensibility and preservation of original
>media types being just two benefits

In-line capabilities is very important, and should be even more emphasized.
However, whether to display the inlined information in the document,
display it in in a spearate window, or leave it as a link should be the
decision of the browser/user, and not the author. A helper app could be
able to display a media type within any document displayed by a browser,
and is supported by the UI object mechanisms (OpenDoc, OLE, etc). Helper
apps is more in accordance with modern software paradigms than having one
fat browser that can do it all.

-- Terje <Norderhaug.CHI@Xerox.com>
   <URL:http://www.ifi.uio.no/~terjen/>