[whatwg] Installed Apps

On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson <ian at hixie.ch> wrote:

>
> It seems like a direct solution to these would be to have a way for Web
> pages to expose a service that clients could subscribe to, which could
> send up database updates and notifications. That way, no script runs on
> the client, but the server can still update the client whenever needed.
>

Yeah, this is an interesting idea, although I'm envisioning apps that
support offline use requiring what amounts to a sync process with
app-specific conflict resolution, etc - I think this would be difficult to
support with this kind of general platform. But, agreed, this is better than
nothing - at the very least, an application could use it to sync down
changes to a "staging area" for later resolution once the app itself starts
up.


>
> I don't understand why workers can't reduce latency. What is the latency
> that must be reduced which workers can't help with?
>

As I understand it, the big problems are 1) loading/parsing/executing
N-hundred K of javascript for an app like gmail is slow, 2) initializing
application data structures from data that must be sent down from the server
(or loaded from the database) is also slow (and by "slow", we may only be
talking on the order of hundreds of milliseconds). Workers don't do much for
either of these, especially when you are launching a web app for the first
time.


>
> > SharedWorkers are overloaded to provide a way for pages under the same
> > domain to share state, but this seems like an orthogonal goal to
> > "parallel execution" and I suspect that we may have ended up with a
> > cleaner solution had we decided to address the "shared state" issue via
> > a separate mechanism.
>
> Shared state is addressed by the Web Storage and Web Database features;
> the shared workers are intended to provide shared computation.
>
>
Sure, although I'd say that "persistent storage is addressed by the Web
Storage and Web Database features". Shared state is also addressed, but
that's not the primary goal. If I have a tree of objects that I'd like to
share between two pages, telling me to serialize it into name/value string
pairs, write it into Web Storage, and then have the remote side read it out
is not a satisfying (or performant) solution.


>
> > So (and forgive me for restating), it seems like hidden page addresses
> the
> > following problems that gmail and other large web apps are having:
> >
> > 1) Loading large amounts of Javascript is slow, even from cache.
>
> The solution is to make loading the JS faster, not to load it and use the
> user's resources regardless.
>

I agree. I don't think that forcing pages to stay resident to reduce JS load
times is a good solution. An ideal solution would be for browsers to be
inherently faster, to enable this for the entire web, not just for
"installed apps".


>
> > 2) Loading application state from the database is slow.
>
> I don't see how a hidden window can solve this. Could you elaborate?
>

The data would be always cached in memory and shared across instances. But,
yeah, Netscape 6, etc. My expectation for persistent workers was that these
workers would try to have a minimal ram footprint, for exactly that reason
(used primarily for generating notifications and keeping the data store in
sync with the server, not as a persistent memory cache).


>
> > 4) There's no way to do things like new mail notifications, calendar
> > notifications, local updates of your email inbox, etc when the browser
> > is not open.
>
> It seems a system dedicated to this could solve this problem in a much
> simpler and more efficient way than running background windows.
>

Yeah, I'm somewhat leery of the "canned RSS-feed"-style solution to
notifications (our vision for notifications is that they are scriptable and
more interactive than just a dumb text + icon). But it's possible that a
simple static feed may cover some portion of the use cases - hopefully we'll
have more real-world use cases once the webkit notification API ships in a
browser. Additionally, any server-side-feed-based solution has the
implication that it won't work for offline apps. If I am using a web
calendar, I want my event notifications regardless of whether I'm online or
offline (the event may have been added while I'm offline and never synced to
the server at all).

-atw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090804/bf0a5883/attachment-0001.htm>

Received on Tuesday, 4 August 2009 09:48:56 UTC