On Jul 21, 2009, at 9:15 PM, Adrian Bateman wrote:
While it might not be the perfect solution (we know the web far from
ideal and is a lot of compromise), this type of proposal would be a
lot more compelling to me if I could say "This is what we have to
add, this is how, and here are the use cases that make it valuable"
with a roadmap for extending what people are already building
instead of something brand new.
Would you mind explaining the last point "with a roadmap for
extending
what people are already building instead of something brand new." for
me? I would definitely strive to make the proposal more compelling.
What I'm asking for is a more unified proposal that says "If you
have already implemented AppCache, here's what you add to make the
same cache provide the additional functionality needed to enable
these additional use cases." This will inevitably be a compromise
from what a pure implementation looks like (your current DataCache
spec, say) but lots of the web is necessarily a compromise because
it builds on prior art that might not have been ideal but has been
specified, built and deployed (and not always in that order).
This would allow people to form a judgement about whether the
additional use cases are worth the additional effort instead of
whether the additional use cases are worth yet another cache. I
think the ship has already sailed on AppCache and we can't undo that
even if we wanted to and I don't think a competing solution is the
right approach.
What kind of extensions/changes to AppCache would be acceptable at
this point? In a previous exchange with Ian, he declined to consider
DataCache like extensions to ApplicationCache for HTML5, which might
be the reasonable thing to do. I can of course put together a
proposal, but it would be good to know from browser vendors what their
preferences are in this matter.
I am open to the idea of incrementally evolving AppCache to be more
supportive of DataCache requirements.
Regards,
Nikunj
