Re: AppCache post-mortem?

On Tuesday, May 14, 2013, Dominique Hazael-Massieux wrote:

> Hi All,
>
> Thanks a lot for the excellent points that have been brought up in this
> thread; I'd like to propose a summary of where I think we are, and would
> like for volunteers to step forward to bring up more concrete plans that
> we can include in our proposal.
>
> * technical work item: partial cache update; Tobie and Chaals at least
> agree this is an important use case, and presumably have a reasonable
> idea of what the requirements are; Alex has looked into the
> (non-negligible) amount of work that would be needed to make this true,
> and believe NavigationController is a first step in the direction that
> would make this possible.
> It would be great if Tobie, Chaals and Alex could caucus to document the
> requirements and challenges for that particular piece of technology;
> this would be a great contribution to a potential follow-up
> specification work.
>

My current plan with the Navigation Controller is to continue to iterate in
conversation with developers and vendors using the github repo and issues
system as a way to note and address concerns. When the design looks to be
more stable, it will be circulated more widely, including in
public-webapps. At that time, the Chrome team is on the hook for an early
implementation to validate the design and I will be writing spec text for
it.


> * structural challenge: there seems to be consensus that it is currently
> too hard for developers to influence the course of a spec, even when the
> state of the related technology is close to being unusable.
>

This mis-charachterizes the issue: developers care about specs and
standards incidentally. What they *really* want is a way to change the
world which they must live in -- and that world is defined by the browsers
that vendors with the largest footprints deploy. We have ample evidence of
easy-to-change specs that nobody implements and nobody is helped by.

What we can do is to help create better, higher-signal channels to funnel
developer feedback to the few places it can actually matter; lending the
W3C's bully pulpit to developers who feel the pain but are known to be
elected representatives of a much larger group would go a long way in
eliminating the instinct of vendors to write off individuals.


> Several proposals have been voiced to help reduce that barrier:
> - make it much easier to submit bug reports, with a bug squad that would
> actually triage and dispatch bug to the relevant working groups as
> needed
> - make it easier for developers to provide more qualitative and
> quantitative feedback on various technologies via surveys
> - get developers effectively represented in the W3C process via a new
> class of membership or through an elected representative
>
> As Alex pointed out, getting more developer feedback is only useful if
> that feedback has real influence on the course of our various
> technologies, incl. in their implementation in browsers — so an
> important aspect of making this work is to determine what parameters of
> the way we gather or represent that feedback will make it truly
> influential.
>
> I believe these 3 proposals have merit and can bring a very positive
> impact on W3C (well beyond our gap with native); but as they stand,
> they're still mostly vaporware, so I would need volunteers willing to
> dig further into them to turn them into more concrete proposals on which
> we could elaborate. Any taker? Robin? Alex? Yehuda?
>

I honestly think this all hinges on the ability and wilingness of the AC to
understand how screwed we are regarding developer feedback today. My sense
is that it's just not on their radar yet.


> (I'll also ping our devrel team since this whole thread is very relevant
> to them)
>
> Dom
>
>
>