On Aug 6, 2008, at 5:48 PM, Aaron Boodman wrote:
On Wed, Aug 6, 2008 at 2:20 AM, Maciej Stachowiak <[EMAIL PROTECTED]>
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
