On 6/21/11 11:26 AM, Marcos Caceres wrote:
I agree that the focus should be the Web, but if other things benefit
from the security and design decisions, all the better, no?
Sure. I just don't think we should be doing things that are targeted
only at non-web situations.
The above still applies. This doesn't mean that "anything goes" once
you leave the http:// realm.
I think that's where we disagree (though "the web" is not restricted to
http:// for what it's worth).
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.
Yes, but I don't think that W3C working groups should be the ones
defining extension security models or performing that scrutiny.
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).
The big difference is that extension hosts can add whatever backdoor
APIs they desire and this is perfectly OK; it's NOT OK to do that on the
web.
For that purpose it doesn't matter what languages are used to interface
with the APIs.
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.
Why should it be the W3Cs remit to standardize an API that several
browsers happen to use for their extension API?
The API should (or should not, whichever) be standardized based on its
web usage. If browsers want to additionally standardize their extension
APIs, that seems fine to me, but not something the W3C should be
spending resources on.
If not, then I need to take all the relevant
bits from Web Storage and fold them into the Widgets Interface
specification.
Widgets Interface is not quite the same thing as extension interfaces.
Having a Widgets dependency on Web Storage is a good reason to consider
taking Web Storage to Rec.
But then of course you have to deal with the fact that Web Storage is
not actually implemented per spec in Chrome, say (nor will it be in
Gecko once we move to a multiprocess model).
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.
Do we?
If some company starts using a half-baked web API internally for
something and then we figure out that it's half-baked and drop it
entirely, are we throwing the baby out with the bath water?
Now the Web Storage situation is somewhat different, because actual
web-facing UAs implement it. But that's what should determined what
happens to Web Storage, not who else not on the web has ended up using
it. In my opinion.
But that's like saying: "The HTML WG should not concern itself with
the needs of PHP,Perl, etc. developers."
Yep.
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).
Sure.
A similar issues applies here: alternative systems make use of these APIs and
do their
best to conform to the spec.
That last part is arguable, but let's posit it.
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.
This last part I don't necessarily agree on.
All of which brings us back to the question of how we want to take this
to Rec given that implementations do not match the spec wrt the storage
mutex?
-Boris
