<div dir="ltr"><div class="gmail_quote">
<div dir="ltr">
<p>I'd like to offer more justification for Michael Nordman's "scriptlet" proposal. </p>
<div>We've spent the last year or so modifying an existing online application to make it work offline. A secondary motivation was application speed. We used Google Gears to enable this. Although we had some success, we also had challenges. Here are some of the big ones:</div>

<ol>
<li><strong>Significant architecture change</strong>. Our web pages are built on the server without much concern for separation of application logic and user data. User data is usually just "baked in" to the page. In captured/offline mode, we have to serve a generic page that can fill in user data via javascript. This required changing the online application in significant ways just to support offline functionality. And, it required forking the code in many places, leading to maintenance difficulties.</li>

<li><strong>All-or-nothing captured mode</strong>; i.e., once a URL is captured, it is always served from offline cache. This means if we encounter a bug in the offline app, it's not easy to fall back to the online app. We could serve the offline app off a different URL space, but that makes for harsh transitions between online and offline mode; e.g., on a flaky connection.</li>

<li><strong>Single sign-on was hard</strong>.</li></ol>
<div>How I think Michael's proposal addresses these:</div>
<ol>
<li>Some applications have cleaner separation of app and user data than others, but one consistent point of clean separation common to all web apps is the HTTP layer, between client and server. Michael's proposal would allow applications a hook at precisely this point. Most client javascript could remain unchanged. XHR servlets would be replaced with client side scriptlets. Server-side templates could be fairly easily migrated to client-side counterparts that populate the template from a local data store.</li>

<li>These scriptlets could also offer a failure mode that would fall through to the online app.</li>
<li>We had to jump through all kinds of hoops to get single sign-on to work. We have to have 2 separate manifests containing all our app URLs, one protected by a cookie and one not. This proposal wouldn't completely ease this problem, but if we're executing a script before the page is loaded we have more options for redirecting to another page when not authenticated, more similar to the way most online authentication schemes work.</li>
</ol>
<div>Also, there are some cases where Javascript simply is not powerful enough. An example we hit recently is dynamic data in the header (e.g., meta tags, styles). We have many cases where these change dynamically. There are ways to get around this (put the dynamic page in an iframe, construct HTML in javascript, and writer it into the iframe), but I think it's clear that this is not a great solution. This is processing that should happen before the page is handed to the browser.</div>

<div> </div>
<div>- Philip</div>
<div> </div>
<div>> *Scriptlets - or dynamic namespace-handlers [new idea]*</div>
<div>></div>
<div>> Something we wrestled with in the process of putting together the Gears</div>
<div>> LocalServer was the distinction between intercepting requests for urls and</div>
<div>> identifying the appropiate cached resource for that request. We ended up</div>
<div>> with a declarative manifest file, similar to but different from what is</div>
<div>> contained in this spec. This wasn't an altogether satisfying answer. The</div>
<div>> expressiveness of the language to match/filter requested urls is limited in</div>
<div>> Gears and this spec shares that same characterization.</div>
<div>></div>
<div>> Something else we've wrestled with in Gears was having to do awkward</div>
<div>> redesigns in corners of a web application in order to 'take it offline',</div>
<div>> single-sign-on for example. In general, anywhere an application relies on</div>
<div>> HTTP features more than HTML to influence navigation or conditional resource</div>
<div>> loading, it's difficult to address with a static cache.</div>
<div>></div>
<div>> So I'd like to propose extending this spec to incorporate 'dynamically</div>
<div>> generated responses'. I think this capability fits into this corner of the</div>
<div>> HTML5 spec because this is most directly useful in the "Offline Web</div>
<div>> Application" scenario. The basic idea is to execute application code</div>
<div>> (script) to produce responses to intercepted resource loads. The application</div>
<div>> code is executed in the background and can formulate a response</div>
<div>> asynchronously.</div>
<div>></div>
<div>> Some handwaving where this could hang off of this spec</div>
<div>> * Modify namespace-handlers entries to have an attitional attribute to</div>
<div>> indicate that they are to be executed rather than returned</div>
<div>></div>
<div>> And some handwaving at what a scriptlet can do...</div>
<div>> * Can read the request headers and POST body</div>
<div>> * Can set response status code and headers (redirects)</div>
<div>> * Can generate a textual response body</div>
<div>>  * Can designate a non-executable cached resource to be returned in response</div>
<div>> * Can decide to 'bypass' handling of a request and defer to the usual</div>
<div>> resource loading</div>
<div>> * Can decide to perform the usual resource loading, but to have the response</div>
<div>> added to the appCache</div>
<div>> * Can access HTML5Database APIs</div>
<div>> * Can utlize XmlHttpRequest to communicate with a server</div>
<div>></div>
<div>> This would obviously be significant addition to the spec, but i do think</div>
<div>> this is worth consideration in the context of 'offline applications'. Based</div>
<div>> on observations of app developers wrestling with Gears, there have been</div>
<div>> several pain points. The HTML5ApplicationCache addresses one of them</div>
<div>> with per-application caches. This addition would address the second of</div>
<div>> them.  (Another pain point has been application deployment).</div>
<div>></div></div></div><br></div>