[whatwg] Offline Web Applications feedback

[Maciej Stachowiak]

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

XML will be ugly even before we extend it.

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

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.

Regards,
Maciej