Re: Server-side data conversion and Internet bandwidth (was: Re: Multi column layout question.)

Jon Wallis (jw@scitsc.wlv.ac.uk)
Mon, 26 Jun 1995 07:52:01 +0100


>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*.
>
>
>What we really need are guidelines, and for HTML authors to follow them.
>For example, I propose the following for _inline_ images:
>
> * 8-bit (256 color) images (can link to 24-bit if desired)
> * 72-dpi resolution (can link to high-res if desired)
> * Reasonable image sizes, like max 470 pixels wide for
> title graphics and navbars (again, can link if desired)
> This also ensures that images will fit without scrolling
> within default window sizes of Mosaic and Netscape browsers
> on typical 13-15" monitors (it defaults to same width on my
> 17" monitor, as a matter of fact)
[snip]

This all seems to be getting out-of-hand - HTML is now getting so complex
(by comparison with HTML "1" anyway) that it is no longer fulfilling its
original purpose (or at least it's harder to see the wood for the trees).

I agree with the responsible use of images (and strongly promote it in my
teaching),
but having to take account of everyone's hardware when you write HTML is
simply ludicrous - one reason HTML was A Good Thing was precisely that it
was h/w *independent*.

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

A while back there was some interest in MHEG - a far more complex protocol
than HTTP, but it does address this sort of problem - i.e., client-server
negotiation over how to supply and present components of multimedia. AFAIK
it's on the verge of becomming a standard (it was a "Draft", last I heard)
and deserves some attention. I haven't heard MHEG mentioned in connection
with the Web for quite some time.

Just some semi-incoherent thoughts (it's 7.45 am (BST) monday morning and
therefore too early for heavy thinking.)

--
Jon Wallis         Senior Lecturer in Information Systems Engineering
School of Computing & I.T., University of Wolverhampton, UK - WV1 1SB
Tel/Fax +44 (0)1902 322203/322680   http://www.scit.wlv.ac.uk/~cm1906
------------Opinions are mine, not those of my employer--------------