Re: Media Queries and optimizing what data gets transferred

A technical discussion including input from all stake holders is always
welcome.
An "X vs. Y" debate when X and Y are not mutually exclusive and do not
cover all of each other's use cases, is usually counter productive, and
quickly degrades to a "Spiderman vs. Superman" type of debate.
IMO, two separate "How to improve {X,Y}"  discussions are usually much more
productive.

Specifically, a server side image adaptation solution, while not ideal
(mostly because of caching issues), is in many cases the only solution. The
first example I can think of is content providers with legacy content
stored in a legacy CMS. These content providers often cannot modify their
(legacy) markup, even if they wanted to, which they rarely do.
They are deploying server-side based solutions *today*, both proprietary
and open-source, based on UA sniffing, device screen size tables, etc.
Currently, they simply forgo public caching by using either "Cache-Control:
private" or "Vary: User-Agent". The client-Hints proposal would enable
these solution to apply *some* public caching, which is better than none.
The Client-Hints proposal can possibly be improved, but as I stated
earlier, it is better to have that discussion separately.

This is why, while I personally wouldn't recommend a server-side based
solution to people creating new content, I believe they have their place.
If I had to pick sides, I'd pick client-side solutions, since IMO they are
more future friendly. Fortunately, I don't have to.

Yoav




On Thu, Jan 31, 2013 at 1:28 AM, Fred Andrews <fredandw@live.com> wrote:

>
> > With that said, I don't think a "Media Queries vs. Client hints" debate
> is productive.
>
> I think standards should not be adopted without at least a technical
> discussion and input from all stake holders.
>
> > IMO both client-side & server-side solutions have a place, each with its
> slightly different use-cases and slightly different trade-offs.
>
> Could you please elaborate on why you think the client-hints proposal in
> particular has a place?
>
> There appear to be two distinct proposals:
>
> 1. Client-side adaptation: the server informs the client of the available
> resources and the client uses the client-side state to make a choice.
> Pros: the user can choose the selection algorithm; browser vendors can
> innovate; the user can keep their state secure at the UA; the server does
> not have to deal with data collection issues; only a small set of distinct
> available resources need to be keyed in the cache; new resources only need
> to be download when one of these distinct choices changes; the UA can reuse
> a resource already available (such as resizing an image on hand); no
> changes are required on the server or the CDN; developer tools can help
> insert and optimized images and resource options into the HTML and then the
> content can be delivered statically or with less server/CDN complexity.
>
> 2. Client-hints based server-side adaptation: the client sends the server
> a range of client-side state and the server uses a secret algorithm to make
> a choice. Cons: The input parameter space is large and each combination
> requires a separate cache key which is more demanding on the cache; any
> change to the input parameters requires a re-validation request to confirm
> if a resource choice has changed; the client is not able to make informed
> decisions to reuse resources on hand if the client-side state changes (for
> example it can not resize an image on hand); users are required to share
> potentially private state which creates data collection problems for the
> server; users who choose not to share their private state are excluded;
> requires adoption of the client-hints standard; requires sending the
> resource choices to the client anyway to handle UAs that do not implement
> or have disabled the client-hints header and this leads to yet more cache
> duplication.
>
> It is clear that client-side adaptation solves all the technical problems
> that client-hints based server-side adaptation offers and that client-side
> adaptation offers no advantages and significant disadvantages.  The
> proponents have failed to address the issues and some replies are rather
> arrogant and insulting which leads me to believe they have no answers.
>
> cheers
> Fred
>
>