[whatwg] Gears design goals

[Ian Hickson]

On Wed, 13 Jun 2007, Aaron Boodman wrote:
>
> The Gears' teams goals for LocalServer were:
> 
> * To support seamless (non-modal) transitions between online, offline, 
> and the browser-is-confused-and-thinks-you're-online-but-really-you're- 
> not (wireless that you have to login to, slow DNS, and crashed servers 
> that are serving 500s are all good examples of this last situation).
> * To allow users to access the application from the same URL whether 
> they are online or offline.
> * To support atomic updates of applications so that you always have a
> consistent version when you go offline.
> * To allow the capture of arbitrary URLs. The canonical example would
> be attachments in web mail.
> * Good, webby, autoupdating characteristics. We didn't want it to be
> possible for web developers to push a broken version of their app
> which could never get unbroken. In fact, we would love this to be as
> close to webby as possible, without sacrificing the goal of always
> being in a consistent state.
> * Simple enough to use without sophisticated server-side
> infrastructure (again, you can think of this as webbiness -- we want
> developers to be able to author this with Notepad).
> * To make it as simple as possible to migrate existing AJAX
> applications to be offline-enabled.

I believe the spec handles all these cases.


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

This isn't handled. The application caches what it gets, and thus stays 
logged in.


> * To allow the capture of file uploads for later re-posting to the
> server. Again, think web mail.

I'll handle this as part of Web Forms changes. Mozilla has experimental 
support for an API to do this, though it needs work to handle large files.


On Tue, 26 Jun 2007, Aaron Boodman wrote:
> 
> 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?
> 
> 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.

It could be kind of weird, yes. I'm not convinced it's a blocker.


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

That seems like a better design.


On Wed, 27 Jun 2007, Robert O'Callahan wrote:
> 
> http://www.campd.org/stuff/Offline%20Cache.html

Right now the spec doesn't have an "isLocallyAvailable()" API, though you 
can walk the list of locally-available dynamic entries in the cache, so 
you can work around that ineffeciently.


On Fri, 29 Jun 2007, Aaron Boodman wrote:
> 
> It seems like right now, all items in a domain implicitly form an atomic 
> group. Is that right?

It's actually not domain-restricted; it's all items in a manifest.


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

Yeah, that's currently the case. Is that a problem?


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

The spec scopes it to application caches, which are identified by their 
manifest URI, so we don't have that problem.


On Sat, 30 Jun 2007, Robert O'Callahan wrote:
> 
> 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.

In the spec, this is actually allowed.


On Fri, 29 Jun 2007, Andy Palay wrote:
>
> So I don't know why one would want to maintain atomicity at the domain 
> level as opposed to the application level. When I run an application I 
> want to make sure I get the latest version of the application. Not sure 
> why it would mean that I want to make sure that I update all the 
> applications from that domain. This could place an unnecessary load on 
> the servers for no great gain for the user.

I agree.


On Sat, 30 Jun 2007, Robert O'Callahan wrote:
>
> Simplicity, mainly. Scoping updates (and the offlineResources list) to 
> the domain level means we don't have to define a new abstraction that 
> delimits application boundaries. And it lets us avoid any issues with 
> partially overlapping applications.

The spec doesn't avoid these issues. It does handles them, though.


Please let me know if I missed anything in this thread. I didn't reply to 
everything as the messages sort of went around in circles. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'