[whatwg] several messages

[Ian Hickson]

On Wed, 19 Sep 2007, Maciej Stachowiak wrote:
> 
> 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?

Agreed.


> 2) Many offline web apps will let you [...] 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.)

I think we provide features that are enough to do this now, though not in 
the way you really describe.


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

Indeed, though we don't support the part after the OR.


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

I think the spec allows you to get this effect, though not really in this 
manner.


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

I don't understand what the difference between an online app and an 
offline app would be in this world.


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

Indeed, that's what the spec has now.


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

That's basically what the spec has now.


On Thu, 20 Sep 2007, Aaron Boodman wrote:
> 
> I think having a feature where an offline page can be served for all 
> URIs with a certain prefix makes sense. It is basically a superset of 
> the current Gears ignoreQuery feature, and it is something that users of 
> our API have asked about.

Right.

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