Re: REGISTRAR
Richard W Wiggins <WIGGINS@msu.edu>
Message-id: <9307140413.AA27501@dxmint.cern.ch>
Date: Tue, 13 Jul 93 23:56:08 EDT
From: Richard W Wiggins <WIGGINS@msu.edu>
Subject: Re: REGISTRAR
To: Rob Raisch <raisch@ora.com>, www-talk@nxoc01.cern.ch
In-reply-to: Your message of Tue, 13 Jul 1993 16:05:11 -0400 (EDT)
Status: RO
...
>> I thinkwork is needed on parameters to hte representations
>> like
>> image/gif
>> is all very well, but
>> image/gif height=200 width=400 colours=8
>> provides better information for the server, allowing it to
>> select or generate an image more accurately, and save bandwidth.
> .....
> it can serve it only as: image/jpeg colours=24
> and leave the retrieval decision to the browser, (which most times
> is less powerful and feature-ful than the server),
> would it not be a better decision to have the browser tell the server
> what capabilities it had, and let the server make the proper
> conversions to serve it in an appropriate form?
...
> The other way round the server must tell the client what *possible*
> forms the property can be served in, and this quickly becomes
> unmanageable. (Consider that GIFs are available with the following
> attributes: width, heigth, colour(bits), dots-per-inch, aspect)
>
></rr>
Hmmm, sounds like negotiation is what's called for, eh?
The Gopher+ model allows the server to offer the client multiple
views, and the client gets to pick what it wants. That could
easily extend to the idea of the server holding data in one form,
and offering several views (that don't physically exist), offering
to translate to the form the client asks for.
Of course, in many cases the client will launch an external viewer
and won't really know for sure what in fact is best for that viewer.
/Rich Wiggins, Gopher Coordinator, Michigan State U