[whatwg] Offline Web Applications feedback

[Aaron Boodman]

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

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

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.

- a