- From: Aaron Boodman <aa@google.com>
- Date: Fri, 29 Jun 2007 10:53:24 -0700
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
Received on Friday, 29 June 2007 10:53:24 UTC