[whatwg] Gears design goals

[Aaron Boodman]

Sorry it took me awhile to respond. Work intruded.

On 6/26/07, Robert O'Callahan <robert at ocallahan.org> wrote:
> 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.

That sounds good. Gears team has also considered that you could get
consistent versions without the hard version number we currently have
in the manifests.

It seems like right now, all items in a domain implicitly form an
atomic group. Is that right?

A couple issues some Gears people brought up with this:

* It's likely to significantly slow down revalidation. There could be
many, many resources linked with the programmatic api (again, think of
attachments). All these would have to be revalidated each time the app
is viewed.

* It seems like atomic groups and domains are not 1-to-1. Lots of
times separate applications are hosted on the same domain but in
different directories. I guess it's not dangerous to revalidate all
apps under a domain when any are viewed, but it seems like a waste.

You could mitigate the first issue by allowing the developer to say
whether a certain resource should be part of the domain's atomic
group. I am not sure how to mitigate the second issue except for by
telling developers to use separate domains for separate applications.
Maybe this is not a big problem.


Another thought that we had was that it would be good if whatever you
can do with the <link> tag syntax, you can also do programmatically.
It may be difficult to hook into IE deep enough to implement the link
tag syntax.


> > 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.
>
> 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.

Fair enough. And if application developers want to support multiple
offline logins, they can still write their app in a way to support
that.

- a