[whatwg] Offline Web Apps with Open-Ended URI Spaces (was Re: Offline Web Apps)

[Maciej Stachowiak]

On Sep 13, 2007, at 3:59 PM, Ian Hickson wrote:

> On Thu, 13 Sep 2007, Aaron Boodman wrote:
>
>> Maybe you were asking how you could keep querystring-based urls in  
>> the
>> offline version of Bugzilla?
>
> There isn't an "offline version". There's just one version, it just
> happens to support being online and offline.
>
> By doing this we're basically saying that the query string never  
> gets sent
> to the server anymore. That seems like a huge violation of the URI
> semantics.

Here are my thoughts on the problem of bugzilla and similar  
applications with open-ended URI spaces.

1) It doesn't fit well with the URI model to treat the query part of  
the URI specially. First, it's not in line with the web architecture  
principle that URIs should be treated as opaque as much as possible.  
Second, why treat just the query specially? Many web applications use  
the path to select one of a large and growing number of items.  
Consider events on upcoming.yahoo.com. Event IDs are exactly analogous  
to bugzilla bug IDs, including the fact that they are referenced all  
over the web outside the control of the app itself. But they are  
stored in the path, not the query, for instance <http://upcoming.yahoo.com/event/216441/ 
 >. What's so special about the query?


2) Many offline web apps will let you want to make changes, including  
not just changing existing items, but also creating new items. To do  
this, at minimum there needs to be an API to inject a new resource  
into the offline cache programatically, with the data explicitly  
provided. (Let's ignore the syncing problem implicit in an application  
with global IDs allowing offline creation of new items, and pretend  
that syncing when returning to online mode will solve it or that IDs  
will be namespaced by creating user somehow.)


3) Offline-enabled apps with a page per resource (like bugzilla or  
upcoming) and which allow editing offline will need to be changed so  
that at least in offline mode each page can suck its relevant data  
from the offline database to update itself, OR manually generate an  
updated page to stick into the offline cache.


4) To suck down all the items a user cares about into a local  
database, you need to suck down the data, but also have some way to  
get at the page when offline. It's not strictly necessary to pull all  
the pages from the server. You could alternately use the API to  
explicitly add an item to the offline cache, per item #2, and do a  
bunch of client-side work to generate and save an offline copy of each  
page. For that matter, each might be an identical template that just  
knows how to suck down the data from the net or the local database as  
appropriate.


5) Now, given 2, 3 and 4, it seems like the online and offline  
versions of the app must necessarily diverge a little bit, if the  
offline app is to offer any form of editing while offline.


6) It's potentially costly to download data mulltiple times, so if you  
pull the remote data into a local database, you won't also want to  
pull every page reflecting that data, instead you will want to  
generate templates client-side and insert them into the offline cache.  
However, it seems like a relatively small step from there to having a  
single fallback page to be used for all URIs that are part of the app  
but haven't gotten downloaded in the course of normal use. And this  
would be a huge optimization, since it would save the client the need  
to manually generate each page for a resource of interest that has not  
yet been visited.

Given point #1, I think this should be based on textual prefix  
matching of the URI, not just dropping the query (the scheme and  
authority sections should be treated specially, of course, it should  
not be allowed to have a fallback page in someone else's security  
domain). This will allow matching paths and also matching only  
specific kinds of queries (where the first parameter is set to some  
specific value, say). However, to make offline and online mode diverge  
as little as possible, I think perhaps such fallback pages should  
apply only when offline. When online, the UA should go to the real  
page. With the prefix-based fallback page solution, I'm not sure it  
will be necessary to also support individual client-generated pages.


Thoughts?


Regards,
Maciej