W3C home > Mailing lists > Public > public-webarch-comments@w3.org > October to December 2004

Re: PR-webarch-20041105

From: Håkon Wium Lie <howcome@opera.com>
Date: Mon, 29 Nov 2004 15:58:46 +0100
Message-ID: <16811.14630.45512.506928@howcome.oslo.opera.com>
To: public-webarch-comments@w3.org
Cc: www-tag@w3.org

Also sprach Chris Lilley:

 > The comment about reduced size resulting from server-based processing
 > was not, however, referring to this aspect at all. Instead, it was
 > referring to the work of the DI working group, whose CC/PP framework for
 > server side content adaptation allows, among other things, images and
 > video to be tailored for the device. If the original content references
 > an image that is 800 pixels wide, and the phone screen is 200 pixels
 > wide, then sending the original image rather than a downsampled one
 > merely makes the download 16 times larger for no benefit.

Ok. Yes. That wasn't clear in the original draft.

 > I understand
 > that Opera has a server based product that does these sorts of
 > transformations.[2]

Indeed.

 > To resolve this ambiguity and more clearly describe the tradeoffs for
 > the two extremes of the spectrum, the following revised text is
 > suggested. Please let us know what you think of it. it will be discussed
 > in the next couple of days at the TAG f2f.

Good. Your revised proposal is close to where it should be. I have
the following comments:

 >   Note that when content, presentation, and interaction are separated by
 >   design, agents need to recombine them. There is a recombination
 >   spectrum, with "client does all" at one end and "server does all" at
 >   the other.

(I'd add "end of the spectrum" (or just "end") to the end of the above
paragraph to make it easier to read.)

 >   There are advantages to each: sending device capabilities to the server
 >   (for example, using CC/PP) allows tailoring of the content to specific
 >   devices (such as mobile phones). For example links can be adjusted to
 >   point to lower resolution images, smaller video or no video at all,
 >   giving a faster download; if the content has been authored with
 >   multiple branches, the server can remove unused branches too. In
 >   addition a small amount of client side computation is saved. However,
 >   this makes the content more specific to a particular device, reducing
 >   caching efficiency.
 > 
 >   On the other hand, recombination on the client makes the delivered
 >   content applicable to a wider range of devices, improving caching
 >   efficiency. 

How about:

  On the other hand, recombination on the client makes the delivered
  content applicable to a wider range of devices. This improves caching
  efficiency and gives users more presentation options.

 >   It can be tailored to particular groups of devices by
 >   using media specific style sheets. For textual content with a regular
 >   and repeating structure, the combined size of the text content plus
 >   the stylesheet is typically less than that of a fully recombined

"stylesheet" -> "style sheet"

 >   content; the savings improve further if the stylesheet is reused by
 >   other pages.

ditto.

 >   In practice a combination of both approaches is often used, tailored
 >   to the particular content.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Monday, 29 November 2004 14:59:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:37:33 GMT