PSA: publishing new WD of Service Workers on November 13

2014-11-11 Thread Arthur Barstow
Jungkee and Alex created a new Working Draft of Service Workers for 
publication as a Technical Report on November 13:


  
http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-service-workers-20141113/


If anyone has any major concerns this proposal, please speak up as soon 
as possible.


-Thanks, AB





Re: New approach to activities/intents

2014-11-11 Thread Dimitri Glazkov
On Mon, Nov 10, 2014 at 8:14 PM, Brendan Eich bren...@secure.meer.net
wrote:

 Dimitri Glazkov wrote:

 Domenic's question still needs addressing separately, but just a quick
 response here -- the API roc described there is different. Tubes are just
 like talking to a worker or any MessagePort. There is no extra API surface
 emerging from getContext-like function call.


 Any getContext or postMessage protocol is inherently not
 object-detectable, at least not at the string-keyed level.

 In principal, as bz said, the tension between extensions and standards
 motivates supporting extensions, and I share your desire to support
 experimentation so long as it is consensus-oriented. We want to avoid
 overlarge jumps by one proprietor, who both risks failing to bring along
 competitors step by step, and seeming to abuse any market power it may
 possess.

 So we want to support extension, extensibility, in ways that don't lead to
 bad game-theoretic and real-world outcomes, e.g. ActiveX PKI in Korea.
 There's no silver bullet or algorithm to do this, but API style matters
 (object detection vs. non-detection; gentle-peoples' agreements about how
 proprietary/particular an API to try).

 The JS SIMD work definitely experiences this tension. Do we want a union
 of all (SSE, NEON, AVX2) vector instructions? Intersection may be too
 small, and emulation may be too slow to be worth using. The
 http://github.com/johnmccutchan/ecmascript_simd issues cover this well,
 and show good particularized thinking.

 To particularize without object detection is hard.

 In any event, IMHO native stacks are not killing the Web, nor are native
 stacks evolving willy-nilly on random and arbitrarily rapid schedules or
 via message-based API settings. Apple and Android are at most annual
 big-release OSes, e.g. I welcome counterexamples.

 Sorry to be skeptical. Object detection, extensible-web-manifesto
 low-level APIs, avoiding indefinitely scoped or lifetime proprietary
 extension mechanisms in favor of incrementalism, all seem better to me.

 /be



I would like to reframe this conversation in a slightly more layered
context. Your scepticism is appreciated, but I also would like to make sure
we're on the same page in regard to the tension and our collective
understanding of the situation. So, here goes.

I thought about this a bit and realized that we first need to have a common
criteria to evaluate whether we even need something like Tubes. That should
be done before we get into mechanics of the solution. I apologize for
jumping the gun. And I apologize even more to poor op whose conversation we
hijacked.

So I came up with the following Capability Availability Success Criteria:

Given any capability on a modern computing device and a developer who wants
to use it, what is a) the acceptable delay between when this capability
becomes available on the web platform vs. first being available on a native
platform, and b) the likelihood that this capability will ever be available
on the web platform.

If we're aiming at years, not months, and 60-80%, then we're already
successful.

If we're hoping to hit weeks, not months and 100%, we need something
like Tubes.

If it's something in between, maybe there are other options.

Setting the bar in terms of these numbers seems like a very charter-ey
thing to decide and agree upon. We should probably do that.

:DG


Re: New approach to activities/intents

2014-11-11 Thread Robert O'Callahan
I still don't see how exposing an API via MessagePorts is in any way better
than exposing an API via WebIDL. Can you describe with concrete examples
how this makes life better for implementors or authors? I've read your
presentation but I did not see the answer there.

Furthermore I don't see any necessary connection between MessagePorts vs
WebIDL and the issues around rapidly bringing experimental APIs to the Web.
Are you claiming that it's quicker and easier to add MesagePort-based APIs
to browsers than using WebIDL?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.


Re: New approach to activities/intents

2014-11-11 Thread Dimitri Glazkov
On Tue, Nov 11, 2014 at 12:28 PM, Robert O'Callahan rob...@ocallahan.org
wrote:

 I still don't see how exposing an API via MessagePorts is in any way
 better than exposing an API via WebIDL. Can you describe with concrete
 examples how this makes life better for implementors or authors? I've read
 your presentation but I did not see the answer there.

 Furthermore I don't see any necessary connection between MessagePorts vs
 WebIDL and the issues around rapidly bringing experimental APIs to the Web.
 Are you claiming that it's quicker and easier to add MesagePort-based APIs
 to browsers than using WebIDL?


I would like to state explicitly that as of
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0376.html, I
withdraw the proposal of Tubes as the exact solution to the problem in lieu
of the need to first formulate a decent problem statement -- in the form of
the criteria I proposed.

:DG


Bringing APIs for experimental hardware/software to the Web

2014-11-11 Thread Robert O'Callahan
On Wed, Nov 12, 2014 at 6:24 AM, Dimitri Glazkov dglaz...@google.com
wrote:

 Given any capability on a modern computing device and a developer who
 wants to use it, what is a) the acceptable delay between when this
 capability becomes available on the web platform vs. first being available
 on a native platform, and b) the likelihood that this capability will ever
 be available on the web platform.

 If we're aiming at years, not months, and 60-80%, then we're already
 successful.

 If we're hoping to hit weeks, not months and 100%, we need something
 like Tubes.


I don't think we should set targets for a) and b) and hit those targets no
matter what the cost. We need to do the hard work of evaluating tradeoffs
case by case. I assume everyone agrees that when there are no hard
tradeoffs to make, of course we'd like to have nice things.

We can have a productive discussion about how to bring APIs for
experimental hardware and software to the Web faster. Subject changed to
suit. Here's my problem statement:

We have a set of traditional goals for the Web platform: backward
compatibility, device independence, multiple interoperable implementations,
long-term durability, coherence, ease of use, safety, etc. People
frequently release new hardware and software with new capabilities that
don't fit into existing Web APIs. Can we expose these capabilities to Web
developers with very low delay, without violating some of our existing
goals? If we can't, what tradeoffs are we willing to make?

If this is the discussion you want to have, then I will reveal some ideas
:-).

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.


Re: Bringing APIs for experimental hardware/software to the Web

2014-11-11 Thread Dimitri Glazkov
On Tue, Nov 11, 2014 at 3:01 PM, Robert O'Callahan rob...@ocallahan.org
wrote:

 On Wed, Nov 12, 2014 at 6:24 AM, Dimitri Glazkov dglaz...@google.com
 wrote:

 Given any capability on a modern computing device and a developer who
 wants to use it, what is a) the acceptable delay between when this
 capability becomes available on the web platform vs. first being available
 on a native platform, and b) the likelihood that this capability will ever
 be available on the web platform.

 If we're aiming at years, not months, and 60-80%, then we're already
 successful.

 If we're hoping to hit weeks, not months and 100%, we need something
 like Tubes.


 I don't think we should set targets for a) and b) and hit those targets no
 matter what the cost. We need to do the hard work of evaluating tradeoffs
 case by case. I assume everyone agrees that when there are no hard
 tradeoffs to make, of course we'd like to have nice things.

 We can have a productive discussion about how to bring APIs for
 experimental hardware and software to the Web faster. Subject changed to
 suit. Here's my problem statement:

 We have a set of traditional goals for the Web platform: backward
 compatibility, device independence, multiple interoperable implementations,
 long-term durability, coherence, ease of use, safety, etc. People
 frequently release new hardware and software with new capabilities that
 don't fit into existing Web APIs. Can we expose these capabilities to Web
 developers with very low delay, without violating some of our existing
 goals? If we can't, what tradeoffs are we willing to make?

 If this is the discussion you want to have, then I will reveal some ideas
 :-).


I think that's a reasonable problem statement. There are two problems with
it:

1) it makes an assumption that everyone on this forum wants very low delay
and all capabilities. I don't know if that is true, though I definitely
want to believe it.

2) it's not as focused as my formulation on actually setting a target for
ourselves, which makes me worried we'll end up in the same loosely
incoherent state we always end up.

Nevertheless, I am optimistic. I would like to have this discussion and
hear your ideas.

:DG


Clarification of CSP sandbox and workers

2014-11-11 Thread Deian Stefan

Hey guys,

I am implementing CSP for Workers in Firefox, but like to get a
clarification on workers and the sandbox flag. Currently, a Worker can
inherit or be accompanied by a CSP header. As written, the implications
of the sandbox directive on the Worker context is not clear.

[Following up on https://github.com/w3c/webappsec/issues/69]

Arguably most of the sandbox flags don't make sense for Workers, but the
empty directive (i.e., just sandbox) and sandbox allow-same-origin can
have reasonable semantics.  So, if a Worker inherits the CSP from the
owner document (or parent worker in later specs) or is accompanied by a
CSP header which has the 'sandbox' directive, should the worker script's
origin be set to a unique origin?  Or should we just ignore (and
appropriately warn about) the sandbox flag for Workers and address the
need for sandboxed Workers separately?

Thanks,
Deian


signature.asc
Description: PGP signature


Re: CfC: publish a WG Note of Fullscreen; deadline November 14

2014-11-11 Thread Tab Atkins Jr.
On Sat, Nov 8, 2014 at 5:43 AM, Domenic Denicola d...@domenic.me wrote:
 From: Arthur Barstow [mailto:art.bars...@gmail.com]
 OK, so I just checked in a patch that sets the Latest Editor's Draft points 
 to Anne's document
 https://dvcs.w3.org/hg/fullscreen/raw-file/default/TR.html.

 I think it would be ideal to change the label to e.g. See Instead or 
 Maintained Version or Replaced By. Framing the WHATWG as a source of 
 Editor's Drafts for the W3C is unnecessarily combative.

I use a replaced by wording on specs I've moved elsewhere; see
https://tabatkins.github.io/specs/css-color/ for an example.

~TJ



Re: New approach to activities/intents

2014-11-11 Thread Brendan Eich

Dimitri Glazkov wrote:
I thought about this a bit and realized that we first need to have a 
common criteria to evaluate whether we even need something like Tubes. 
That should be done before we get into mechanics of the solution. I 
apologize for jumping the gun. And I apologize even more to poor op 
whose conversation we hijacked.


So I came up with the following Capability Availability Success Criteria:

Given any capability on a modern computing device and a developer who 
wants to use it, what is a) the acceptable delay between when this 
capability becomes available on the web platform vs. first being 
available on a native platform, and b) the likelihood that this 
capability will ever be available on the web platform.


If we're aiming at years, not months, and 60-80%, then we're 
already successful.


If we're hoping to hit weeks, not months and 100%, we need 
something like Tubes.


If it's something in between, maybe there are other options.


There are definitely other options. I think you've backed yourself into 
a dialectical corner. MessagePorts are not the primitive droids we're 
looking for! For one, JS SIMD cannot and should not use them. Even 
witha  sync-on-this-async-API-call general API, they are not the right 
droid.


I see roc has replied (we are not communicating via back-channels) so 
I'll stop here.


The actor model is beautiful and in part true, but it's not workers or 
MessagePorts, and it's not the right droid. Even if we add actors to the 
web platform, we will need to make particular, non-actor, synchronous 
API additions. These require careful design and (multiple browser) 
implementation with web developer feedback validation. Sorry, no easy 
answers. I do not think we need weeks not months, in any event (as noted 
vs. native stacks). We need intentional design with user (web dev) testing.


/be