[whatwg] Offline Web Apps

[Andrew Fedoniouk]

----- Original Message ----- 
From: "Ian Hickson" <ian at hixie.ch>
To: "Andrew Fedoniouk" <news at terrainformatica.com>
Cc: <whatwg at whatwg.org>
Sent: Friday, August 24, 2007 11:39 AM
Subject: Re: Offline Web Apps


> On Fri, 24 Aug 2007, Andrew Fedoniouk wrote:
>>
>> There are two distinct types of applications (in context of this topic)
>>
>> 1) Online web applications. 2) Occasionally connected web applications 
>> (OCWA).
>>
>> These two groups differ significantly in their design.
>> So what exactly you are trying to make "offline aware"?
>
> Both. Basically we're aiming at the same kind of stuff as the Google Gears
> offline mode APIs, but using a standards-based API. So things like Google
> Reader, Yahoo! Mail, or even MSN Live Map Search or whatever it's called
> this week.
>

Google Gears has three modules so far:

1) Application delivery module, a.k.a. LocalServer;
2) Local database module;
3) Async JS execution module, a.k.a. WorkerPool.

Local database module is clearly a part of OCWA functionality. Client side 
DB
cannot make any good if application is not designed to use it.

Async execution has nothing too specific to online/offline - this is what JS 
will benefit
in general.  (I believe that 'yield' and friends in JS should allow to do 
this without any
additional features - generator functions use their own stack - so are 
threads generally
speaking)

So we can discuss/focus on Application Delivery Module.

Applications like you've mentioned (Google Reader, etc.) consist of
so called mostly static pages/resources/scripts and use local DB requests 
and/or
RPC (remote procedure calls, AJAX kind of thing) to get relatime
data (JSON or HTML fragments) to compose final UI.

In principle such applications (their client side part)
can be packaged in something like zip file and delivered as a whole to
the client machine. In this case distribution of them is not different from
ordinary zip file downloading and caching.  This is very close to
what Java uses in years (ClassLoader, NetworkClassLoader and
other already invented wheels).

Application can consist of multiple distribution units (WADU -
web application distribution unit - zip file for example).
To be able to use resources from other DUs the page should have
mechanism similar to include/use directives. This could be some
separate manifest/configuration file or simply translation directives like:
<meta use="/module-a.zip" as="/module-a/" >

Such a <meta> will allow to support old UAs (that do not support packaging)
- web server can contain web app as packaged modules together with
the old style tree of resources.

Pages (HTML) of application can be mostly static - this means
that they may have some dynamic islands. As an example:
<include src="/some-advertisement/fragment.htm" />.
That will include html content (and only, no scripts or CSS)  from other 
locations.
Update cycle is defined by http headers of refered html.
<include> is purely client side thing - sort of lightweight <iframe> means
is not a part of server side html processing.

Therefore, I think, in context of the discussion it makes sense to
take a look on better distribution schemas too.

Andrew Fedoniouk.
http://terrainformatica.com