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
