[whatwg] Gears design goals

On 6/30/07, Aaron Boodman <aa at google.com> wrote:
>
> 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?


"Right now" as in what I've proposed, yes. Not "right now" as in what's
implemented on Firefox trunk :-)

A slight twist is needed actually: an atomic group consists of all resources
in a domain that are used by pages in the same domain. We allow cross-domain
references but we do not allow them to create consistency requirements.

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.


For the specific case of attachments, in our model those could be placed in
their own domain. For resources where you actually want to access the
contents on the client, wouldn't work.

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

That's what I would suggest, yes.

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.


I think we're there already (although in our proposal, all you'd have to do
is traverse the <link> tags on onload, dynamic changes to the link tags
after that have no effect).

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/20070630/cd209438/attachment.htm>

Received on Friday, 29 June 2007 16:15:02 UTC