[whatwg] Offline Web Applications feedback
mjs at apple.com
Wed Aug 6 19:08:20 PDT 2008
On Aug 6, 2008, at 5:48 PM, Aaron Boodman wrote:
> On Wed, Aug 6, 2008 at 2:20 AM, Maciej Stachowiak <mjs at apple.com>
>> 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
>>> 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 think that the unnamed columns make it difficult to use, because you
> have to remember which column does what. I've used a similar
> text-based format, the Firefox chrome.manifest format, and I found it
> difficult for the same reason.
> If we ever needed to have columns that were optional for a given
> section, it would become difficult to see if they were specified
> because of the lack of names.
> If rows ever get long with more than a few columns, there is no
> ability to wrap them with the given format. This would come for free
> with many other formats.
> If we ever needed to add any kind of hierarchy, we would have to
> reinvent something like XML, JSON, or YAML.
> To me, the idea of inventing a custom one-off format for this is ugly.
> I realize this is somewhat a matter of taste (unix uses lots of
> line-based format and hey, it works fine for them), so I will drop
> this and just leave it as a vote for XML.
XML will be ugly even before we extend it.
>>> - I like the fallback entry feature, but I don't understand why it
>>> coupled to opportunistic caching. On the Gears team, we frequently
>>> requests to add a feature where a certain pattern of URLs will try
>>> 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
>>> 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.
> Ok, I don't think this feature needs to be in this spec then, IMO.
> HTTP caching essentially does the same thing, anyway. If it is in the
> spec, I think it should be separated from the fallback feature.
HTTP caching can't promise that all the resources you load when your
Web App loads will be available offline. I will agree the feature does
not seem essential.
More information about the whatwg