[whatwg] several messages
ian at hixie.ch
Tue Oct 9 21:41:14 PDT 2007
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
> 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
> 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
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.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg