[whatwg] Offline Web Applications feedback

[Michael Nordman]

On Wed, Aug 6, 2008 at 2:20 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Aug 5, 2008, at 11:30 PM, Aaron Boodman wrote:
>
>  Some quick notes/questions...
>>
>> - I think the manifest should be some structured, extensible format
>> such as XML or JSON. The current text-based format is going to quickly
>> turn into a mess as we add additional fields and rows.
>>
>
> We've implemented the current format already in WebKit (available in
> nightlies and the Safari 4 Developer Preview).
>
> The format does not seem to have much call for extension and seems easy to
> understand and use as-is.


I would prefer to see something more extensible, XML comes to mind.
Extensibility would accommodate the addition of experimental sections and
entry attributes while retaining compatibility with what has been formally
adopted into the spec.


>
>  - I like the fallback entry feature, but I don't understand why it is
>> coupled to opportunistic caching. On the Gears team, we frequently get
>> requests to add a feature where a certain pattern of URLs will try to
>> go the network first, and if that fails, will fall through to a
>> certain cached fallback URL. But nobody has asked for a way to lazily
>> cache URLs matching a certain pattern. Even if they had, I don't
>> understand what that has to do with the fallback behavior. Can we
>> split these apart, and maybe just remove the opportunistic caching
>> thing entirely?
>>
>
> I think the idea of opportunistic caching (as I understand it) is that the
> author can be lazy, and not write a manifest at all.
>

Seems like there are a few different use cases to accommodate. Spitting this
up would add clarity and allow us to make indpendent decisions about  which
should be in or out of the spec.

1) Being lazy about listing images and css located in well known
directories, automatically caching as the app runs.

2) Hijacking parameterized requests and returning a local resource without
incurring any network traffic.

3) Falling back on a local resource iff server/network error.

The first item is really a convenience, the latter two are more significant
features. Gears does the second one. The third item has been requested of
the Gears team, but that one does present interesting versioning issues /
sharp edges (not to mention implementation nightmares for extension
developers).

What if... the server is running a newer version of the app than is
currently in use... depending on type of resource it is, i think there could
be some unexpected consequences, especially when you consider local SQL data
with an expected schema.


>
>>
>> - It seems odd that you request a resource and the server returns 400
>> (bad request) we fallback. Maybe it should just be up to the server to
>> return an error message that directs the user to the fallback URL? I'm
>> not sure about this one, looking for feedback.
>>
>> - Maybe this is obvious, but it's not specified what happens when the
>> server returns a redirect for a resource that is being cached. Do we
>> cache the redirect chain and replay it?
>>
>> - In practice, I expect the number of URLs in the online whitelist is
>> going to be unbounded because of querystrings. I think if this is
>> going to exist, it has to be a pattern.
>>
>
> I agree the online whitelist should allow patterns of some form.
>
>

Without the "fail if not represented in the manifest" behavior, the online
whitelist may not be critical, although this idea has come up with Gears
too, configuration such that...
    <prefix>...&bypassAppCache=1
... any url of that form goes thru to the default resource loading.



>
>  - I know you added the behavior of failing loads when a URL is not in
>> the manifest based on something I said, but now that I read it, it
>> feels a bit draconian. I wish that developers could somehow easily
>> control the space of URLs they expect to be online as well as the ones
>> they expect to be offline. But maybe we should just remove the whole
>> thing about failing loads of resources not in the manifest and online
>> whitelist for v1.
>>
>
> I think it would be hard to add later after the fact.


Not sure the "fail if not represented in manifest" is a good idea either...
are there unintended consequences lurking here... what does this do in the
face of mashups?


>
>
> Regards,
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080806/f9366e50/attachment-0001.htm>