Re: AppCache post-mortem?

On 06/05/2013 22:19 , Tobie Langel wrote:
> It's funny, now that I'm thinking about it, how this issue keeps
> coming up.
>
> For example, Web developers behind large JS app have been asking for
> the past 2-3 years for a secure way to send diffs and have them
> applied instead of sending the new compiled JS file whenever there's
> a one line change in what often amounts to half a mega bite of JS or
> more.
>
> Some have ended up implementing this themselves, creating security
> issues in the process. Others just bust their user's cache every time
> there's a new version of the app, which with modern teams could be
> multiple times a day.
>
> However, whenever this is brought up within standards bodies or with
> implementors, with descriptions of existing implementations in
> production, it is usually considered in a really demeaning way ("Web
> developers should not use LocalStorage to store files, it's slow,"
> "Web developers should not use LocalStorage to store files, it's not
> secure," or "Eval is evil.")
>
> I can guarantee our next problem on mobile (once AppCache is solved)
> will be patching JS files. I guess this will have to wait another 2
> years before it is considered.

There are several mismatches that make developer feedback, especially 
when it is for new features rather than for problems with existing ones, 
poorly taken into account.

• By and large, things happen when someone does them. If you come to a 
group and give it a draft, something might happen. If you just ask for a 
feature, even assuming there's interest it'll take a while to make it to 
the top of someone's todo list. I'm not saying that the developers' 
fault, just pointing out that it's a factor.

• People tend to want to know if there's implementer interest before 
committing the time to write-up a spec, even if sketchy. But implementer 
interest can be hard to gauge. It can also be rather fickle. Again, not 
blaming anyone.

• At least some of the feedback comes in the form of a grumpy gripe in 
the middle of a more or less unrelated discussion. I'm not blaming Tobie 
here ;-p

• Developers often find it hard to address the right group. That's 
entirely the W3C community's fault.

• The group charter system isn't flexible enough; it's impossible to add 
a deliverable without rechartering, which takes time and effort. In 
Shakespeare's words: "The first thing we do, let's kill all the 
lawyers." Some form of delta chartering process might be useful here.

I'm probably missing some factors, those are the ones off the top of my 
head. Some things that might help:

• I don't know what the exact remit of the current DevRel team is, but 
translating between the needs of developers and what standards people 
do, including helping the former outline use cases and make their 
argument is definitely something I'd put under DevRel in general.

• Maybe we should have one single point of entry "Request a Feature" 
page. It would offer the proper guidance on how to propose something, 
and help send it to the right place (possibly by including some 
indirection).

• Spec The Web Forward events. Modelled after TestTWF, go town to town 
gathering input from developers, explaining how to write use cases, how 
to use shims as evidence, how to help, etc.

• A simple form into which you can enter an element name, CSS property, 
JS interface or member, and be given the information about which spec 
and group it is from so that you know who to contact (and where the bug 
tracker is).

Just some thoughts.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 7 May 2013 13:54:07 UTC