Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That’s pretty complex for a caching solution. Not to mention the edge cache would need to keep multiple copies of the same document to diff them, which makes it completely unusable for anything with quick turnover.

With HTML5 Offline (App Cache) you could easily do this on the application level, of course. And with SPDY you can just fetch the fragments separately without any performance penalty. Basically current trend is to enable more gradual caching instead of implementing some higher level resource multiplexing.

Biggest missed opportunity in my opinion? Preparsed DOM/XML. E.g. Fast Infoset[1].

[1] https://en.wikipedia.org/wiki/Fast_Infoset



I think you're misunderstanding what I'm asking for. As I've said, I've already implemented that kind of caching in JS. It's really simple. The problem is, local storage and cookies are not ideal implementations.


Local storage is a bad fit for caching. You can compose the document from smaller fragments and leverage the browser cache. It’s simple AJAX. That’s what I meant by gradual caching.

I thought a bit about your solution, and I guess it’s doable using existing technology AND leveraging gradual caching without JS.

Browsers would just have to support Xinclude[1].

For example:

    > GET /foo

    < 200 OK HTTP/1.1
    < ETag: 1
    <?xml version="1.0"?>
    <html xmlns="http://www.w3.org/1999/xhtml
          xmlns:xi="http://www.w3.org/2001/XInclude>
       <head>...</head>
       <body>
          ...
          <p><xi:include href="fragment" parse="text"/></p>
       </body>
    </html>
Using standard HTTP/1.1 session protocol this would require additionally requesting /foo/fragment, SPDY can just use SS push.

    > GET /foo/fragment

    < 200 OK HTTP/1.1
    < Etag: 1
    […]
Now on refresh conditional GET for /foo hits cache, and conditional GET for /foo/fragment doesn’t. Abracadabra: partial caching.

    > GET /foo 
    > If-None-Match: 1

    < 304 Not Modified HTTP/1.1

    > GET /foo/fragment
    > If-None-Match: 1

    < 200 OK HTTP/1.1
    < Etag: 2
    […]
While it looks like some new technology, it’s simple really. Browsers already compose pages by fetching scripts, images, embedded objects, iframes. This is not that different.

Moreover, this approach provides backwards compatibility, because if the browser doesn’t resolve XInclude, you can just do that yourself using AJAX.

This solves your problem, but requires changes only on the client side.

[1] https://en.wikipedia.org/wiki/XInclude




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: