Re: RfC: moving Web Storage to WG Note; deadline June 29

On Tue, Jun 21, 2011 at 4:33 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 6/21/11 10:25 AM, Marcos Caceres wrote:
>>
>> Seems your idea of "the web platform" is very idiosyncratic and
>> limited. It almost sounds like you are advocating "a modern web
>> browser with no extensions installed is the Web platform" or "it's not
>> in the HTML/WAHTWG spec, so it's not the Web platform". Yet, a
>> significant number of users of Web browsers use browser extensions:
>> Moz boasts "2,521,539,729 add-ons downloaded" - that's a lot of
>> download for something that is not part of the "Web platform" yet are
>> part of a Web browser.
>
> I think you're confusing "parts of a web browser" and "things that need to
> affect the design of web APIs".
>
> Extensions are very commonly used, yes.  That doesn't mean we should be
> designing web APIs around the needs of extensions.

I agree that the focus should be the Web, but if other things benefit
from the security and design decisions, all the better, no?

So please don't get me wrong, I'm not advocating explicitly thinking
about extensions or anything else during the design of Web APIs: just
that the APIs sometimes can be used in other places without
modification. So when we get to a cross roads like this one, it's
important to stick our head up and see who else came along for the
ride and what will happen is we pull the rug out (i.e., is what's the
collateral damage? and should we care?).

> In particular,
> extensions can, and often do, have access to APIs that are not exposed to
> web pages and that can be used to serve whatever non-Web needs those
> extensions have.

The above still applies. This doesn't mean that "anything goes" once
you leave the http:// realm. Extensions are still interacting with an
extremely hostile environment: the Web. Thus should be subject to the
same or more scrutiny, given their bridging between both worlds.

>> Perhaps you don't use browser extensions, which might lead you to
>> believe that they are not an essential part of a web browsing
>> experience. For people like me (and seems like a pretty significant
>> part of the Firefox, Chrome, and Opera user base), they are a
>> fundamental part of the browsing experience and of the platform.
>
> There is a big difference between "the browsing experience" and "the
> platform".

Not so much when they are made of the same fundamental stuff (html,css,js).

>> Again, what part of the Web Storage running on chrome:// or widget://
>> is an issue or violates the spec?
>
> I haven't examined the code in detail, so I have no idea whether there are
> such parts.  But why does that matter?

Because we are debating if this becomes a WG Note or a W3C
Recommendation based on Web Storage's value to the "Web Platform". If
the Web Platform includes packaged Web applications, then I would want
Web Storage to go to Rec. If not, then I need to take all the relevant
bits from Web Storage and fold them into the Widgets Interface
specification. I would prefer not to do that because I think Web
Storage is useful as a Recommendation beyond Widgets (and has already
been widely deployed in the wild in all browsers.)

>> A good API and specification is one
>> that has wider applications than that for what it was originally
>> intended.
>
> And a bad API and specification is one that is designed with wider
> applications in mind that never really materialize, saddling the original
> applications with suboptimal API.  We have tons of Web APIs like this.

That we can agree on. The API has been picked up and used successfully
in other contexts (browser extensions, widgets). The API did not set
out to do this: it just happened.

> I'd rather err on the side of addressing known needs well than on the side
> of hoping additional needs arise.
>
> Perhaps that's the fundamental disagreement we have?

We completely agree here: "work to use cases, don't fix the world".
It's just that the API ended up being used in more places which was
expected, so now we have a "throwing out the baby with the bath water"
situation.

>> I obviously didn't make myself clear: I'm talking about this
>> particular (Web Storage) API and how it interoperates in two browser
>> extension systems (Chrome and Opera).
>
> And I'm saying that interoperability of extension systems should not be a
> concern for W3C working groups, even if it happens to occur for a particular
> API.

But that's like saying: "The HTML WG should not concern itself with
the needs of PHP,Perl, etc. developers." That is true only to the
extent that the HTML markup needs to be flexible enough to be
generated server-side easily (or crafted by hand). A similar issues
applies here: alternative systems make use of these APIs and do their
best to conform to the spec. The Web Storage spec does not restrict
the applicability of the API to http://, hence the Working Group has
to deal with the consequences when others find innovative uses for the
API. That's were we are now:)

>> If you can't prove that it is different and it does not fully conform to
>> the Web Storage spec, then
>> you don't really have a case.
>
> My case is that we should not be spending time standardizing extension APIs,
> period, and instead focus on things that are needed for the web.

Agree.

> The fact
> that some of them happen to agree anyway is irrelevant to that point.

I don't agree: only because our conception of the Web platform differs
in scope a little. But I understand where you are coming from now.

Thanks for the discussion.

-- 
Marcos Caceres
http://datadriven.com.au

Received on Tuesday, 21 June 2011 15:27:25 UTC