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

[whatwg] Gears design goals

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 27 Jun 2007 11:26:50 +1200
Message-ID: <11e306600706261626m726d48b9h15d823328711ddbe@mail.gmail.com>
On 6/27/07, Aaron Boodman <aa at google.com> wrote:
>
> Great! So where do we differ on the implementation of those goals? Is
> there an up-to-date spec I can read?


http://www.campd.org/stuff/Offline%20Cache.html

Right now I think we're missing just one thing from your list of goals
(excluding the vexatious "multiple resources for one URI" goal): a way to
get consistent updates without relying on JAR files (and hence changing
URIs). As I mentioned earlier, I think we can get that by simply stating
(and implementing!) that updates to all offline-cached resources in a domain
--- that were requested by pages in the same domain ---  occur atomically as
a group, similar to what Gears does. That leaves one issue, which is the
ability to add new resources as part of such an atomic update; to get that,
we probably should add an offline-manifest DOM API or <link> type, which
pulls in a JSON manifest and requests all the resources in it.

> > - 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.
> > >
> > Understood, but this seems to add substantial complexity to the model.
> > Is it really a big deal to restrict users to one login available
> > offline? A browser can of course support multiple profiles or
> > something similar to address that use case without complicating the
> > development model.
>
> If apps are to be able to transition between online and offline
> seamlessly, that implies that the browser always serves the cached
> version and revalidates in the background, right?


Yes.

If so, that means apps can't serve different resources at the same
> URL, even when a connection is available, which seems like a big
> constraint.


Sure they can. The user can only have one active login per browser session
anyway, so the app just swaps in a whole new set of resources when the user
logs in with a different ID.  The only restriction is that when the user's
offline, they'll only be able to use the last ID that they logged in as.

OTOH, I believe that if I were creating a new Gears-enabled app from
> scratch, I would not use requiredCookie. In fact, I didn't for
> Gearpad. There is only one version of Gearpad for all users, and it
> pulls in the required user-specific resources dynamically.


Let me put the strongest spin on this that I can :-) --- I'm reluctant to
substantially complicate the API for implementors and developers for all
time, just so that some legacy apps can have an easier transition for the
specific case of supporting multiple logins while the user is offline.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070627/9bf9c288/attachment.htm>
Received on Tuesday, 26 June 2007 16:26:50 UTC

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