Yuk! I have a really slow floating-point, so I want to decrease the
preferability settings for JPEGs (assuming servers or clients come out
to support this anytime soon. :-) This doesn't necessarily have to be
a problem, though.
>I don't think we should get hung up about the 5% or 1% of cases which are
>different. Nobody is suggesting getting rid of Accept headers altogether.
>Its just an optimisation that can be applied for a large number of cases.
Just so I have a better idea of this, could you show me what the
default set of Accept: headers for the linemode browser would look
like? It supports text/html and text/plain natively (big deal, don't
even need to declare that) and can handle application/octet-stream
(save it to a file.) What else would go in there? The ubiquitious
*/*?
Mosaic, similarly, handles few types natively; those above, plus
image/gif if it's in the context of inlined images (another domain
where the accepts should be different.)
>In general I would like to suggest a principle that *ALL* areas where there
>is a degree of flexibility should be referenced via URLs. If we tried to
>compress accept groups in a static manner then there would always be a problem
>
>when new accept groups were declared. URLs allow us to deffer the specificatio
>n,
>and more importantly distribute it.
This seems a reasonable approach in general; I just am not sure how
much it will help with this particular application.
-- <A HREF="http://www.cs.indiana.edu/hyplan/mvanheyn.html">Marc VanHeyningen</A>