Memo

Apr. 26th, 2013 05:13 am
akuklev: (Свечка и валокардин)
HTML wrappers [AEK 01621-0]

It's a common thruth that sharing content is better than duplicating it. Usually, almost all pages of a given website share common layout, stylesheets, scripts and background images. Images, scripts and stylesheets can be (and are in most cases) extracted into separate files which are separatelly cached so that the client does not have to download exactly same bytes hundreeds of times. What about common layout? Unfortunatelly not!

Once W3C proposed a solution: XSLT templates which can be attached to an XHTML file as an outer stylesheet. Unfortunatelly they are even more clumsy, overengeneered and unhuman(readable) than XHTML2, so virtually nobody used them. XHTML2 never took off and was superseded by lightweight HTML5. It's time to replace XSLT by a lightweight solution.


The documentThe template
<html wrapper="/template/common">
  <head>
    <title>Contacts</title>
    <blob id="alternate-languages">
     <li><a href="?lang=ru">ru</a>
     <li><a href="?lang=de">de</a>
    </blob>
  </head>

  <dl>
    <dt>Tel:</dt> +49 11223344
    <dt>E-Mail:</dt> bla@bla.com
  </dl>
  ...
</html>
<html>
  <head>
    <link rel="stylesheet" href="/style/theme.css"/>
    ...
  </head>

  <nav>
    ...
  </nav>

  <aside>
    <ul> <<alternate-languages>> <ul>
  </aside>
  <<body>>
</html>
We propose to introduce new optional attribute “wrapper” to the <html> tag and new block elements <blob> to the <head> section. If the “wrapper” attribute is nonzero, load the template, replace the <<body>> placeholder with content of the document and <<id>> placeholders with the content of blobs with corresponding ids from the head of the document. Merge the rest of the document's head into the template's header. Templates can be nested, so process the template's “wrapper” attribute.

This should cover at least 99% of common use cases. The rest can be handled with javascript.

Memo

Apr. 26th, 2013 05:13 am
akuklev: (Свечка и валокардин)
HTTP attachments [AEK 01622-0]

What's the difference between an app and a rich web site? An app can be opened when you're offline and appears immedeatelly when you start it, while the web site needs a second o two when you're online and does not open when you're not, ...unless the whole website is in your cache.

There is a modern trend in website development called client side templating: html is being served with gaps which are then filled in using ajax and updated as necessary. The main advantage is that the skeleton html becomes static resource which can be served with large cache lifetime, which closes the gap between apps and sites.

The drawback is that when a user visits the page for the first time, he or she first loads the static content with gaps (second or two) and then waits another second for the gaps to fill. The solution is to provide the initial content of for the gaps right away as “attachments” to the main (skeleton) html. Each part should be served with its own E-Tag. If the request is not a simple GET, but GET-IF-MODIFIED with a list of E-Tags of already cached parts, only modified parts should be sent. Additionally we propoose a cache control extension “application” for files that should remain available for offline use until the user deliberately removes them.

Example response:
HTTP/1.1 200 OK
Content-Length: ...
Cache-Control: application; max-age=2600000
Content-Type: multipart/mixed; boundary=PART

--PART
Content-Type: text/html
ETag: "686897696a7c876b7e"

<html>
  <head>
    <title>Sweet home</title>    
  </head>

  <div id="news"/>
  ...
</html>

--PART
Content-Disposition: div.news
Content-Type: text/html
ETag: "6876696a7c876jkh"

<div id="news" class="important">
 Major update is comming soon: ...
<div>
Remark: HTTP provides excellent infrastructure for content caching. Every served file can be supplied with cache lifetime and an E-Tag. Suppose http://mydomain.com/image/kitten123.jpg is a static resource that probably will live unchanged under the same name for years. In this case the picture is served with cache lifetime of several months. Image will be cached when the client visits it for the first time and may last in the cache indefinetely long.
– If the client requests http://mydomain.com/image/kitten123.jpg and cached file is not expired, it will be served immedeatelly without contacting the server.
– If the client requests http://mydomain.com/image/kitten123.jpg after cache expiration, the browser would perform a GET-IF-MODIFIED request sending E-Tag of the cached version to the server. If the file was not modified, the browser would get a short and quick "NOT MODIFIED" response with new expiration date of the cached file.

December 2016

S M T W T F S
    123
456789 10
11121314151617
18192021222324
25262728293031

Syndicate

RSS Atom

Page Summary

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 21st, 2017 03:46 pm
Powered by Dreamwidth Studios