W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2007

[whatwg] Gears design goals

From: Aaron Boodman <boogs@youngpup.net>
Date: Wed, 13 Jun 2007 09:43:45 -0700
Message-ID: <f3e92ae50706130943w1cfa9184n64ef388698132ba7@mail.gmail.com>
Before we get too buried in specifics, I wanted to take the discussion
up a level and talk about Gears' overall goals and see where, if
anywhere, they differ from the rest of the community's. If we can
agree on the goals, then I'm confident that with this groups we ought
to be able to come up with a clean implementation.

The Gears' teams goals for LocalServer were:

* To support seamless (non-modal) transitions between online, offline,
and the browser-is-confused-and-thinks-you're-online-but-really-you're-not
(wireless that you have to login to, slow DNS, and crashed servers
that are serving 500s are all good examples of this last situation).
* To allow users to access the application from the same URL whether
they are online or offline.
* To support atomic updates of applications so that you always have a
consistent version when you go offline.
* To allow the capture of arbitrary URLs. The canonical example would
be attachments in web mail.
* To allow the capture of file uploads for later re-posting to the
server. Again, think web mail.
* Good, webby, autoupdating characteristics. We didn't want it to be
possible for web developers to push a broken version of their app
which could never get unbroken. In fact, we would love this to be as
close to webby as possible, without sacrificing the goal of always
being in a consistent state.
* Simple enough to use without sophisticated server-side
infrastructure (again, you can think of this as webbiness -- we want
developers to be able to author this with Notepad).
* To make it as simple as possible to migrate existing AJAX
applications to be offline-enabled.
- One major issue that we found here was that lots of existing
applications serve different resources at the same URI depending on
who is logged in. We could ask these applications to redesign so that
they don't do that, but we would prefer to not have to.

Some of our APIs probably pretty naturally fall out of this list of
goals. Others, not so much. Those others may be things that are ripe
for re-evaluation, and we are happy (eager, even) to do this. We want
this to be tight, happy, loved, and well-used.

- a
Received on Wednesday, 13 June 2007 09:43:45 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:56 UTC