[whatwg] Google Gears and HTML5

On 6/12/07, Aaron Boodman (Google) <gears.team.aa at gmail.com> wrote:
>
> On 6/11/07, Robert O'Callahan <robert at ocallahan.org> wrote:
> > Chris Prince wrote:
> > How do you do that when an ambiguity is discovered during a manifest
> update?
>
> That's a good point, i think all we could do there is throw into the
> environment, which isn't particularly useful, but would at least
> prevent the ambiguity.


What do you mean "throw into the environment"? The update might occur
automatically in which case I'm not sure where an exception would go. And it
seems that preventing the update might lead to the app being unrecoverably
"stuck".

* Rename/copy were motivated by a particular problem we had with an
> internal app that we were playing with. When you would capture files
> using the file upload api while offline, you would need to rename them
> after you found out the primary key of the entity on the server
> because the application would build the URIs based on these PKs. This
> probably could have been solved other ways on the server.


I think the best way to handle file uploads (in an HTML5 context) is to
provide an API that any Web app can use to directly read the contents of a
file input control. That seems conceptually simple and also potentially
useful to all kinds of Web apps, online and offline.

I agree that having overlapping URLs is a pain with the current
> design. It would be nice if URLs were unique. What we found is that in
> many applications, URLs aren't unique. Localization is one example of
> this, but there are many. I think it may not be necessary to have both
> enable/disable *and* requiredCookie, but we probably need something.
> requiredCookie just removes some of the legwork of toggling a bunch of
> stores on and off on each login.


What are the other uses? Are they all situations where the content for a
given URI is stable within a given "logon session"? (As you would expect if
cookies are sufficient to discriminate between the different contents...)

I think restricting URIs to map to just one resource simplifies things a
lot. Another simplification that our model has is that offline resources are
never directly mutated by the client; they are always just a snapshot of
server state. These two properties are very appealing... We can also safely
support cross-domain offline loads (e.g. to get canonical library scripts,
or looking forward to WHATWG-style messaging APIs, cross-domain
communication) which I think is hard to do without the latter property.

I think we can extend our model to support Gears-style consistency without
JARs by adding support for manifests somehow (e.g. <link
rel="offline-manifest">), and then requiring that all offline resources in a
domain (that are used by apps in the same domain*) be updated atomically
roughly the same way Gears does it. But I need to talk to Dave about it...
(* Applications using cross-domain loads don't get any consistency
guarantees for those loads. For example we don't want someone randomly
referencing a missing file under example.com and breaking updates of
example.com's own applications.)

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/20070612/ebbc7163/attachment.htm>

Received on Tuesday, 12 June 2007 02:49:39 UTC