[whatwg] Persistent Scripting Context, was: Offline Web Apps

[Dimitri Glazkov]

I've been sitting on this thought for almost a week, and with no time
in sight to formalize it  into some sort of a proposal, I believe it'd
be better just to blurt it out here. Alex Russell's post was the
proverbial straw (http://alex.dojotoolkit.org/?p=623#more-623).

Overall, I think Ian's latest proposal is good. I am still trying to
wrestle understanding the specifics of Updaters and use cases, but it
looks like a pretty good way to implement offline storage.

Additionally, it appears to be a very elegant way to add an extra
level of scope that is much needed for Web applications. So, here is
the idea:

1. Instead of using "application" attribute, move the declaration into
a separate head element, like link rel="application". This provides
the ability to reference multiple applications and also name each
reference:

<link rel="application" type="text/html" id="dojo"
href="http://dojotoolkit.org/files/manifests/dojo-0-9-0.html">

(I am implicitly suggesting that the manifest is in XOXO format, but
that's another topic for another day)

2. All offline storage rules, outlined in Ian's proposal apply.

3. For each declared application, a scripting context exists. The
context is a JS object and can be accessed by querying
document.application[id], where id is the value of the "id" attribute
on the link element (a bit kludgy, better idea needed here). For
instance:

document.application.dojo.parser = function() { ... }
alert(document.application.dojo.version);

4. The scripting context is persistent for the duration of the browser
session. In other words, it retains scope and values of the context
members across documents, being initialized when the application is
first encountered during a browsing session and shutting down when the
browser session is terminated. I realize how complex this is
implementation-wise.

5. If the document is explicitly mentioned in the manifest of the
application, the context is read/write for this document. Otherwise,
the context is read-only. This allows any developer to use the
application without actually being part of it.

6. In addition to Updater, there are Constructor and Destructor
manifest entries. Their purpose is to initialize scripting context
when the application is encountered for the first time during the
browser session and tear down the context when the session ends.

Obviously, this is very sketchy, but I wanted to capture this in
writing, hoping that it will inspire more concrete ideas.

:DG<