Re: Two years on and still no sensible web storage solutions exist

2012-11-12 Thread Andrew Wilson 
Your best bet is to report implementation/performance issues to the browser
vendors, rather than here, unless you believe that there is something
inherent in the spec that results in slow implementations.

I'd say in the specific case of Chrome, we probably have not optimized for
the case of writing out a 100MB ArrayBuffer - logging a bug at
http://crbug.com describing your use case would be a useful way to have
this addressed, at least on that platform.


On Mon, Nov 12, 2012 at 5:17 PM, Florian Bösch  wrote:

> On Mon, Nov 12, 2012 at 3:49 PM, Kyle Huey  wrote:
>
>> Er, IndexedDB should handle ArrayBuffers just fine.  If you're seeing
>> problems with that that's an implementation bug, not a case that the spec
>> failed to handle.
>>
> You're right it does, I just checked. Nevertheless there are some issues.
>
> This testsite: http://codeflow.org/issues/indexeddb.html
> Putting 50mb takes between 2.5 to 8 seconds. Getting it between 2 to 4
> seconds.
> Putting 100mb doesn't work in Chrome at all and throws an exception on the
> put after half a second.
>
> For comparison, in python:
> Writing 50mb takes between 40-80ms. Reading takes around 50ms.
>
>
>
>

Re: Two years on and still no sensible web storage solutions exist

2012-11-12 Thread Andrew Wilson 
My recollection is that some vendors refused to ever support SQLite, making
a SQL-based standard not really feasible. You can undoubtedly review the
w3c archives to find out more details if you want to know the rationale
they expressed at the time.

It's unfortunate that IndexedDB is still not widely supported by browsers -
I share your frustration. However, as you say, you can write to the
IndexedDB APIs, and use a shim to get support on platforms that do not
support it yet.

-atw


On Mon, Nov 12, 2012 at 9:50 AM, Florian Bösch  wrote:

> I'd like to propose as a constructive strategy not to flame/offend
> everybody right off the bat. I'm sure there's reasons, I'd like to hear
> them, too.
>
>
> On Fri, Nov 9, 2012 at 7:24 PM, Todd Blanchard 
> wrote:
>
>> It has been two years since the following little note was attached to the
>> Web SQL Spec
>>
>> This document was on the W3C Recommendation track but specification work
>> has stopped. The specification reached an impasse: all interested
>> implementors have used the same SQL backend (Sqlite), but we need multiple
>> independent implementations to proceed along a standardisation path.
>>
>> This move has left the web browser world in disarray and has been widely
>> misconstrued by readers to mean "Web SQL is deprecated and will not be
>> supported in the future - better port to IndexedDB".
>>
>> Today, TWO YEARS LATER, we have SQLite on iOS, Android, Chrome, and
>> Safari but no IndexedDB.  On Firefox we have IndexedDB with SQLite
>> available only via a browser extension
>> https://addons.mozilla.org/en-US/firefox/addon/html5-websql-for-firefox/ 
>> (annoying
>> but liveable), and on IE[89] only DOM storage with IndexedDB expected on IE
>> 10.
>>
>> Sources: http://caniuse.com/indexeddb http://caniuse.com/sql-storage
>>
>> As someone who is trying to build an offline web app the works both on
>> browsers and smart phones and needs to store a lot of client side complex
>> data that will require lots of joins - let me just say WTF?
>>
>> Why do we have standards again?  You're not helping.
>>
>> I look around at information on the state of storage options and I read
>> stuff like this:
>> "Since November 18, 2010, the W3C announced that Web SQL database is a
>> deprecated specification. This is a recommendation for web developers to no
>> longer use the technology as effectively, the spec will receive no new
>> updates and browser vendors aren't encouraged to support this technology.
>> The new alternative is IndexedDB which is already available on Chrome 12+
>> and Firefox 5+, and, soon, in IE 10 as well.
>> "
>> Was it really the intent to abandon SQL as a concept because everybody is
>> using the same well tested and portable library?  Are we doomed to never
>> ever having a stable and consistent platform to work on?Because there are
>> no competing implementations for browser accessible SQL database access -
>> everybody settled on one nice bit of code to fulfill this requirement - the
>> specification is dropped and the browser developers drop even trying to
>> implement SQL database access and there is even talk of removing it?
>>
>> WTF is wrong with you people?
>>
>> IndexedDB is fine - add it.  But don't for a second try to tell me it is
>> anywhere near as powerful as having a real SQL database on hand.
>>
>> Also, the hand waving about how it should be possible to add SQL on top
>> of IndexedDB rings hollow.  If it were easy we would have it.  OTOH, going
>> the other way seems pretty easy.
>> https://github.com/axemclion/IndexedDBShim maybe the developers should
>> just pursue this approach with SQLite and call it a day.
>>
>> Absolutely disgusted.
>>
>> -Todd Blanchard
>>
>
>

Re: Sync API for workers

2012-09-02 Thread Andrew Wilson 
On Sun, Sep 2, 2012 at 12:16 PM, Glenn Maynard  wrote:

> On Sun, Sep 2, 2012 at 12:24 PM, Andrew Wilson wrote:
>
>> I am not optimistic that we can do deadlock prevention in the general
>> case with MessagePorts, for the same reason that it's prohibitively
>> difficult to reliably garbage collect MessagePorts when they can be passed
>> between processes.
>>
>
> Would you consider this an implementation-blocking problem?
>

No. To the contrary, I was (poorly) arguing in favor of not making deadlock
prevention a required part of the spec.

Re: Sync API for workers

2012-09-02 Thread Andrew Wilson 
On Sat, Sep 1, 2012 at 2:32 PM, Glenn Maynard  wrote:

> On Sat, Sep 1, 2012 at 3:19 PM, Rick Waldron wrote:
>
>> I can seriously dispute this, as someone who involved in research and
>> development of JavaScript programming for hardware. Processing high volume
>> serialport IO is relatively simple with streams and data events. It's just
>> a matter of thinking differently about the program.
>>
>
> We'll have to professional disagree, then.  I've used both models
> extensively, and for some tasks, such as complex algorithms, I find linear
> code much easier to write, understand and debug.
>
>
> On Sat, Sep 1, 2012 at 3:28 PM, Olli Pettay wrote:
>
>> Proposal 3
>> Worker:
>> postMessage("I want reply to this");
>> var events = [];
>> while (var m = waitForMessage()) {
>>   if (m.data != /* the reply * /) {
>> events.push(m);
>>   } else {
>> // do something with message
>>   }
>> }
>> while (events.length()) {
>>dispatchEvent(events.shift());
>> }
>>
>
> The intent is much simpler:
>
> postMessage("foo");
> var response = getMessage();
>
> You're correct that this wouldn't integrate all that well with libraries,
> since you may end up receiving an unrelated message.  (Trying to deal with
> that is where the bulk of the above comes from--and you probably really
> wouldn't want to dispatch unknown events, since that's effectively making
> *all* events async.)  That's why I originally proposed this as a method on
> MessagePort.  You'd create a dedicated MessagePort to block on, so you
> wouldn't collide with (and possibly be confused by, or discard by accident)
> unrelated messages.
>


Just wanted to point out that all of the arguments for a wait-for-reply API
in workers also apply to SharedWorkers. It's trickier for SharedWorkers
since they use MessagePorts, and we probably don't want to expose this kind
of API to pages (which also use MessagePorts). But I would strongly prefer
a solution that would be applicable to all kinds of workers, not just
dedicated workers.

FWIW, I find the getMessage(timeout) API (sol'n 3 in the thread) preferable
to adding new "send sync message/reply + related events" to the API.
Perhaps exposing this on both Worker and on MessagePort (with appropriate
errors if getMessage(timeout) is called from page scope with timeout != 0)
would be acceptable? I'm not entirely certain what the semantics of
getMessage() are, though - if you grab a message via getMessage(), does
this imply that normal onmessage event handlers are not run (or perhaps are
run after we re-enter the event loop)?

I am not optimistic that we can do deadlock prevention in the general case
with MessagePorts, for the same reason that it's prohibitively difficult to
reliably garbage collect MessagePorts when they can be passed between
processes.


>
> Of course, that means that while you're waiting for messages on the port,
> no other messages are being received, since you aren't in the event loop.
> That's just inherent--nothing else that happens during the event loop would
> take place either, like async XHR.
>
> I'm not sure how to do the "implicit deadlock prevention" if this is
> exposed on MessagePort, though.  (I personally don't find it a problem, as
> I said earlier, but I know that a proposal that has that as an option will
> have a much better chance of being implemented than one that doesn't.)
>
> - The message must be read in order to reply
>>
>
> I'm not quite following here.  You could getMessage at any time, and the
> other thread could postMessage at any time--there doesn't have to be a
> "hey, send me a message" message in the first place at all.  For example, a
> site may have a button that sends a message when clicked.  You don't have
> to jump hoops in order to wait for the "query" message to reply to, as it
> seems you'd have to with the "reply" proposals.
>
> --
> Glenn Maynard
>
>

Re: Web Notifications

2012-06-20 Thread Andrew Wilson 
On Wed, Jun 20, 2012 at 2:36 PM, Andrew Wilson  wrote:
> On Wed, Jun 20, 2012 at 3:17 AM, Olli Pettay  wrote:
>> On 06/20/2012 11:58 AM, Anne van Kesteren wrote:
>>>
>>> Hi,
>>>
>>> The Web Notifications WG is planning to move Web Notifications to W3C
>>> Last Call meaning we don't intend to change it. But we might have
>>> missed something and would therefore appreciate your review of
>>> http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html and any
>>> comments you might have at public-web-notificat...@w3.org.
>>>
>>> Cheers,
>>>
>>>
>>
>>
>> Seems like tags are global. I think they should be per origin.
>
> Hmmm. Doesn't Section 4.3 step 2 restrict tag checking to same-origin?

Apologies, I see this was changed as a result of Olli's email.

Re: Web Notifications

2012-06-20 Thread Andrew Wilson 
On Wed, Jun 20, 2012 at 3:17 AM, Olli Pettay  wrote:
> On 06/20/2012 11:58 AM, Anne van Kesteren wrote:
>>
>> Hi,
>>
>> The Web Notifications WG is planning to move Web Notifications to W3C
>> Last Call meaning we don't intend to change it. But we might have
>> missed something and would therefore appreciate your review of
>> http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html and any
>> comments you might have at public-web-notificat...@w3.org.
>>
>> Cheers,
>>
>>
>
>
> Seems like tags are global. I think they should be per origin.

Hmmm. Doesn't Section 4.3 step 2 restrict tag checking to same-origin?

>
>
> -Olli
>

Re: Shared workers - use .source instead of .ports[0] ?

2012-04-11 Thread Andrew Wilson 
I guess I'm not a big fan of removing ports[] from the connect event unless
we also remove it from MessageEvent entirely. All the same arguments you've
posed here also apply to MessageEvents in general, so I'd be opposed to
removing it in only one place.

I'm somewhat OK with keeping ports[] but also exposing the port through the
|source| attribute, although "it's OK to put different objects in |source|
as long as they all expose an API called postMessage()" feels inelegant to
me - at least it's backwards compatible.

If we're going to make a non-backwards-compatible change (and I'm not
convinced that we should), I think my preferred solution would be along the
lines of the change described by Jonas earlier - leave |source| alone, get
rid of the |ports| attribute from MessageEvent entirely, and expose the
port in the connect event via the |data| attribute. This is more closely
aligned with the new Transferrable support in postMessage() anyway.

-atw

On Wed, Apr 11, 2012 at 2:05 AM, Simon Pieters  wrote:

> On Wed, 11 Apr 2012 09:29:53 +0200, Jonas Sicking 
> wrote:
>
>  I would prefer to expose the port through .source even if we can't get
>> rid of .ports[0] right now.
>>
>
> I think the longer we wait with removing it, the more legacy will be
> created that relies on its existence.
>
>
>  The ports property is basically useless
>> right now except for this one instance and so while I agree that there
>> might be some confusion in the short term, it doesn't seem like it
>> would be a compatibility problem, and long term it seems like a win
>> that authors wouldn't have to worry about the property at all. It
>> might continue to work if we decide that it's needed for back compat,
>> but it seems like we eventually would be able to get rid of it given
>> how new the property still is.
>>
>> / Jonas
>>
>
>
> --
> Simon Pieters
> Opera Software
>

Re: Shared workers - use .source instead of .ports[0] ?

2012-04-10 Thread Andrew Wilson 
Well, the start of this thread stated (emphasis mine):

"One modification is that the 'connect' event's source port is exposed in
.source *instead of* in .ports[0], to make it closer to the API for
cross-document messaging. Maybe we should make this change to Shared
Workers as well."

Not populating ports[0] with the port is a non-backwards-compatible change,
I think. Is there a different proposal on the table now, such as keeping
the current value of ports[0] but additionally setting the source attribute
to the same value?

-atw

On Tue, Apr 10, 2012 at 10:56 PM, Jonas Sicking  wrote:

> On Tue, Apr 10, 2012 at 10:44 PM, David Levin  wrote:
> > What is the backwards compatibility story for websites already using
> > SharedWorkers with the interface that has been in the spec for over a
> year
> > now?
> >
> > There are sites using them. For example, Google Docs uses them and Google
> > Web Toolkit exposes them.
>
> As far as I can see there are no backwards compat breaking changes
> proposed. Are there any particular parts you are worried about?
>
> / Jonas
>

Re: Shared workers - use .source instead of .ports[0] ?

2012-04-10 Thread Andrew Wilson 
On Tue, Apr 10, 2012 at 1:06 PM, Jonas Sicking  wrote:

> On Tue, Apr 10, 2012 at 10:47 AM, Andrew Wilson 
> wrote:
> > To follow up on Jonas' earlier comment, the postMessage/MessageEvent APIs
> > changed to support object transfers after we defined the connect event
> > structure, so it's not unreasonable that we should take another look at
> the
> > connect event to try to make it match the current definition of
> > postMessage().
> >
> > I think the model of connect event we've used in the past
> > (pre-structure-clone-transfer) is as if the creator of the SharedWorker
> were
> > sending a message like so:
> >
> > postMessage("", [newPort]);
> >
> > The recipient then receives a MessageEvent with data="" and
> ports=[newPort].
> >
> > In the new world where postMessage() supports a transfer object, I think
> the
> > appropriate analogous connect event would be to result in a MessageEvent
> > with both the |data| and |ports| attributes pointing at an array
> containing
> > a single MessagePort. I don't think putting the MessagePort as the source
> > attribute is the right model.
>
> Why make .data be an array containing a single MessagePort? Why not
> just make .data be the MessagePort object itself?
>

That's fine with me as well. To be honest, I haven't been closely following
the Transferable discussion, so I wasn't certain what the semantics of the
|data| and |transfer| attributes were (
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#messageport).
If it's valid to just have |data| point directly at a Transferable rather
than a-map-containing-Transferables then that's fine by me.


>
> The .ports property is basically a relic of the time before we had
> Transferrable objects. Even if we all end up implementing it, I think
> we should let authors ignore it once they don't care about down-level
> browsers.
>
> / Jonas
>

Re: Shared workers - use .source instead of .ports[0] ?

2012-04-10 Thread Andrew Wilson 
To follow up on Jonas' earlier comment, the postMessage/MessageEvent APIs
changed to support object transfers after we defined the connect event
structure, so it's not unreasonable that we should take another look at the
connect event to try to make it match the current definition of
postMessage().

I think the model of connect event we've used in the past
(pre-structure-clone-transfer) is as if the creator of the SharedWorker
were sending a message like so:

postMessage("", [newPort]);

The recipient then receives a MessageEvent with data="" and ports=[newPort].

In the new world where postMessage() supports a transfer object, I think
the appropriate analogous connect event would be to result in a
MessageEvent with both the |data| and |ports| attributes pointing at an
array containing a single MessagePort. I don't think putting the
MessagePort as the source attribute is the right model.

-atw

On Tue, Apr 10, 2012 at 10:33 AM, Andrew Wilson  wrote:

> I'll agree that having to use ports[0] to access the MessagePort in a
> connect event has always felt a bit like an API wart. However, I don't
> entirely recall why we wanted to have the connect event use the
> MessageEvent interface. So I'd be uncomfortable with changing connect event
> to not match that interface without understanding why we made those
> interfaces match in the first place (perhaps Ian can chime in here).
>
> I'll also note that the MessageEvent for cross-document messaging has a
> |ports| attribute, so I'm not certain why removing this attribute on the
> connect event "makes it closer to the [cross-document messaging] API" - can
> you clarify your reasoning here? Also, since MessagePort is not a
> WindowProxy, I'm not sure we want to encourage developers to treat them as
> the same by putting them both as the |source| attribute in MessageEvents in
> different contexts, especially since the postMessage() APIs don't precisely
> match.
>
> -atw
>
> On Tue, Apr 10, 2012 at 5:27 AM, Simon Pieters  wrote:
>
>> On Tue, 10 Apr 2012 14:01:47 +0200, Jarred Nicholls 
>> wrote:
>>
>>  On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters  wrote:
>>>
>>>  On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking 
>>>> wrote:
>>>>
>>>>  Sounds great to me. The ports attribute is basically useless except in
>>>>
>>>>> this
>>>>> one instance since ports are these days expose as part of structured
>>>>> clones.
>>>>>
>>>>> Avoiding using it in this arguably weird way in this one instance seems
>>>>> like a win to me.
>>>>>
>>>>>
>>>> I'd like to have an opinion from WebKit and Microsoft about this
>>>> proposal.
>>>> Can someone comment or cc relevant people, please?
>>>>
>>>>
>>> FWIW this to me seems like a good improvement to the intuitiveness.
>>>
>>
>> OK. To make things clear, are you OK with making this change in WebKit?
>>
>>  Since
>>> a MessageEvent interface is being used, qualifying that *source*
>>> WindowProxy
>>>
>>> is populated is all that's needed?
>>>
>>
>> It wouldn't be a WindowProxy, but a port. I'd also make .ports null. The
>> IDL for MessageEvent's source member would need to change type from
>> WindowProxy? to object?.
>>
>>
>>
>>>
>>>> cheers
>>>>
>>>>
>>>>  / Jonas
>>>>
>>>>>
>>>>> On Wednesday, April 4, 2012, Simon Pieters wrote:
>>>>>
>>>>>  Hi,
>>>>>
>>>>>>
>>>>>> In Opera Extensions we use something that resembles shared workers.
>>>>>> One
>>>>>> modification is that the 'connect' event's source port is exposed in
>>>>>> .source instead of in .ports[0], to make it closer to the API for
>>>>>> cross-document messaging. Maybe we should make this change to Shared
>>>>>> Workers as well.
>>>>>>
>>>>>> I think shared workers hasn't seen wide adoption yet, so maybe changes
>>>>>> like this are still possible.
>>>>>>
>>>>>> What do people think?
>>>>>>
>>>>>> currently:
>>>>>> onconnect = function(e) { e.ports[0].postMessage('pong') }
>>>>>>
>>>>>> proposed change:
>>>>>> onconnect = function(e) { e.source.postMessage('pong') }
>>>>>>
>>>>>> --
>>>>>> Simon Pieters
>>>>>> Opera Software
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> Simon Pieters
>>>> Opera Software
>>>>
>>>>
>>>>
>>
>> --
>> Simon Pieters
>> Opera Software
>>
>>
>

Re: Shared workers - use .source instead of .ports[0] ?

2012-04-10 Thread Andrew Wilson 
I'll agree that having to use ports[0] to access the MessagePort in a
connect event has always felt a bit like an API wart. However, I don't
entirely recall why we wanted to have the connect event use the
MessageEvent interface. So I'd be uncomfortable with changing connect event
to not match that interface without understanding why we made those
interfaces match in the first place (perhaps Ian can chime in here).

I'll also note that the MessageEvent for cross-document messaging has a
|ports| attribute, so I'm not certain why removing this attribute on the
connect event "makes it closer to the [cross-document messaging] API" - can
you clarify your reasoning here? Also, since MessagePort is not a
WindowProxy, I'm not sure we want to encourage developers to treat them as
the same by putting them both as the |source| attribute in MessageEvents in
different contexts, especially since the postMessage() APIs don't precisely
match.

-atw

On Tue, Apr 10, 2012 at 5:27 AM, Simon Pieters  wrote:

> On Tue, 10 Apr 2012 14:01:47 +0200, Jarred Nicholls 
> wrote:
>
>  On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters  wrote:
>>
>>  On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking 
>>> wrote:
>>>
>>>  Sounds great to me. The ports attribute is basically useless except in
>>>
 this
 one instance since ports are these days expose as part of structured
 clones.

 Avoiding using it in this arguably weird way in this one instance seems
 like a win to me.


>>> I'd like to have an opinion from WebKit and Microsoft about this
>>> proposal.
>>> Can someone comment or cc relevant people, please?
>>>
>>>
>> FWIW this to me seems like a good improvement to the intuitiveness.
>>
>
> OK. To make things clear, are you OK with making this change in WebKit?
>
>  Since
>> a MessageEvent interface is being used, qualifying that *source*
>> WindowProxy
>>
>> is populated is all that's needed?
>>
>
> It wouldn't be a WindowProxy, but a port. I'd also make .ports null. The
> IDL for MessageEvent's source member would need to change type from
> WindowProxy? to object?.
>
>
>
>>
>>> cheers
>>>
>>>
>>>  / Jonas
>>>

 On Wednesday, April 4, 2012, Simon Pieters wrote:

  Hi,

>
> In Opera Extensions we use something that resembles shared workers. One
> modification is that the 'connect' event's source port is exposed in
> .source instead of in .ports[0], to make it closer to the API for
> cross-document messaging. Maybe we should make this change to Shared
> Workers as well.
>
> I think shared workers hasn't seen wide adoption yet, so maybe changes
> like this are still possible.
>
> What do people think?
>
> currently:
> onconnect = function(e) { e.ports[0].postMessage('pong') }
>
> proposed change:
> onconnect = function(e) { e.source.postMessage('pong') }
>
> --
> Simon Pieters
> Opera Software
>
>
>
>
>>> --
>>> Simon Pieters
>>> Opera Software
>>>
>>>
>>>
>
> --
> Simon Pieters
> Opera Software
>
>

Re: Opening discussion on StreamWorker

2011-11-18 Thread Andrew Wilson 
On Thu, Nov 17, 2011 at 7:30 PM, Charles Pritchard  wrote:

> On 11/17/2011 4:52 PM, Charles Pritchard wrote:
>
>> Currently, Web Workers provides a "heavy" scope for multithreaded Web
>> Apps to handle heavy data processing.
>>
>> I'd like to draw on those specs and create a new lightweight scope useful
>> for various data processing tasks typically associated with stream
>> processing and GPUs.
>>
>> CSS/FX is looking at custom filter tags using WebGL. I think we can
>> implement these in Workers as well. The most important constraints are that
>> the data is opaque: no shared storage allowed.
>>
>> There are many examples of using web workers to apply effects to 32bit
>> pixel data. Those could be easily applied to CSS pixel filters just as
>> WebGL shaders are.
>>
>> River Trail and W16 are showing us ways in which tight for loops can take
>> advantage of multiple cores.
>>
>> Let's look at these use cases and consider a new lightweight worker
>> scope. Nothing but the bare bones, designed and expected to be used for a
>> very specific type of task.
>>
>> Existing CanvasPixelArray processing scripts are a great place to start.
>> I suspect we'll be able to handle other cases, such as stream ciphers.
>>
>> I'm still trying to bikeshed a name on this... StreamWorker,
>> OpaqueWorker, SimpleWorker, DataWorker etc.
>>
>>
>> Please join me in the discussion. I think we can make rapid progress here
>> now that Transferable has matured and we have two moderately-parallel JS
>> implementations.
>>
>>
> To be more clear: here is some in-the-wild code that is similar to what
> I'd expect to produce and consume with StreamWorker:
> http://code.google.com/p/**chromabrush/source/browse/**
> frontend/js/filter.blur.js
>
> Pseudo-code:
> onmessage(data) { for(... data) { data[i] *= fancyness; };
> postMessage(data); };
>
> In doing this, could attach to CSS such as:   img { filter:
> custom(url('basicpixelworker.**js')); }.
>
> The worker may only use postMessage once, and it must send back an array
> of the same size.
> There are no other options, no ways to pass a message to other contexts,
> no File or IDB or other APIs.
> The concept here is to be very restrictive. That way, no data is leaked,
> and it behaves more like a WebGL shader (think GPGPU) than our existing web
> worker context.
>
> If it's rigid, we can get very good performance, high parallelism, and
> modularity. We can also get quick implementation from vendors.
> And they can decide when they want to optimize.
>

Can you clarify what optimizations are enabled by these workers? It's not
clear to me that removing APIs makes starting up a worker any more
efficient, and I don't think significant efficiencies are enabled by
restricting workers to only sending/receiving a single message per
execution.


>
> As a completely different use case, such a simple worker could provide
> stream encryption, or perhaps some other kind of basic but heavy number
> crunching. Since it's just a simple in-out routine, it can be highly
> optimized and easily added into API pipelines.
>
> These workers would still be backward compatible. They could still be used
> as normal web workers. But in their more basic state, they can be more
> lightweight, there are no side effects
> and so they are more appropriate for massive parallelism.
>
> -Charles
>
>

Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]

2011-06-22 Thread Andrew Wilson 
On Wed, Jun 22, 2011 at 2:31 AM, Glenn Maynard  wrote:

> On Wed, Jun 22, 2011 at 4:33 AM, David Levin  wrote:
>
>> Making people use a helper function like that is just making them jump an
>>> unnecessary hoop.
>>>
>>
>> It makes them jump through another hoop to potentially misuse the api.
>>
>
> No, it's another hoop that *everyone* has to jump through to use the API at
> all, so code you write in browser N+1 would also work in browser N where
> fewer classes support transfer.
>

I do understand Glenn's point about convenience, but I generally strongly
prefer APIs that throw exceptions when passed unsupported arguments over
APIs that silently ignore those arguments.

Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]

2011-06-09 Thread Andrew Wilson 
On Thu, Jun 9, 2011 at 11:13 AM, Glenn Maynard  wrote:

> On Thu, Jun 9, 2011 at 1:28 PM, Andrew Wilson  wrote:
> > 1) I'm not completely sure I understand what the new postMessage()
> semantics
> > look like. Since cloning a port is a destructive operation, I like the
> fact
> > that the current postMessage() API requires the developer to explicitly
> pass
> > a list of ports to clone. If we shift to a paradigm where merely
> referencing
> > a port from the object graph is sufficient to do a destructive clone of
> that
> > port, I'm concerned that this will lead to very-difficult-to-debug issues
> > for developers. So I would say that there is value to still requiring the
> > developer to pass a separate "objectsToTransfer" array, even if we
> > automagically fixup references to those transferred objects within the
> > object graph.
>
> I see the list as a set of objects whose mutating structured clone behavior
> should be enabled.
>
> For ArrayBuffer (and most any other object that might be put in here except
> ports), it's object transfer.  For MessagePort, it's MessagePort's cloning
> behavior.  MessagePort would have no non-mutating structured clone behavior,
> so putting a MessagePort in the object graph without putting it in the
> transfer list would be an error, like putting an unclonable object in the
> graph; it would throw DATA_CLONE_ERR.
>
> Likewise, putting a MessagePort in the object graph with APIs like History
> or Web Storage, which use structured clone but not transfer, would throw
> DATA_CLONE_ERR, since the (implicit) transfer set is empty.  (In other
> words, other APIs would be unaffected and throw the same error they do now.)


Great, this makes sense to me too.

Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]

2011-06-09 Thread Andrew Wilson 
On Wed, Jun 8, 2011 at 6:26 PM, Kenneth Russell  wrote:

>
> Thinking about this more, that port could be sent as the data
> attribute of the event instead of the empty string. Then the ports
> attribute on MessageEvent could be safely deprecated.
>
> -Ken
>
>
So a number of different variations have floated around, and I have some
concerns:

1) I'm not completely sure I understand what the new postMessage() semantics
look like. Since cloning a port is a destructive operation, I like the fact
that the current postMessage() API requires the developer to explicitly pass
a list of ports to clone. If we shift to a paradigm where merely referencing
a port from the object graph is sufficient to do a destructive clone of that
port, I'm concerned that this will lead to very-difficult-to-debug issues
for developers. So I would say that there is value to still requiring the
developer to pass a separate "objectsToTransfer" array, even if we
automagically fixup references to those transferred objects within the
object graph.

2) Rather than having some mix of deprecated attributes on MessageEvent to
support SharedWorkers, I'd rather just change onconnect() to take a distinct
event type that has a non-deprecated ports attribute - I've never been
particularly clear why we're reusing the MessageEvent interface for
SharedWorker connect events anyway. Since Safari and Chrome have supported
SharedWorkers for well over a year now, I would be careful about changing
this interface in a non-backwards-compatible manner - however, if we are not
concerned with backwards compatibility, I would change this ConnectEvent to
just have a port attribute that references a single port rather than a
ports[] attribute that references an array that always contains a single
port.

-atw

Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]

2011-06-03 Thread Andrew Wilson 
On Fri, Jun 3, 2011 at 3:23 PM, Glenn Maynard  wrote:

> On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson  wrote:
> > significant motivation. The stated motivations for breaking this API
> don't
> > seem compelling to me given the existence of backwards-compatible
> > alternatives.
>
> This proposal is backwards-compatible.  If the argument is an array,
> nothing changes, so postMessage(..., [ports]) is equivalent to
> postMessage(..., {ports: [ports]}).  (The array-only approach can be
> done compatibly, too; the object version is just an alternative to
> that.)  What's backwards-incompatible?
>

Ah, I missed that piece (to be honest, I haven't been following this
discussion in every detail - I only chimed in because of Jonas' request for
implementation feedback).


> For anyone not looking closely at the IDL while reading this, this
> means deprecating (for whatever value "deprecate" has on the web) the
> ports array in MessageEvent--not the ports parameter to postMessage
> (that's a sequence).
>

Does this affect the API for the SharedWorker onconnect message as well?

Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]

2011-06-03 Thread Andrew Wilson 
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking  wrote:

> On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell  wrote:
> > On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard  wrote:
> >> On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov 
> wrote:
> >>> a) Recursive transfer lists. Allow arbitrary objects, not only
> ArrayBuffers,
> >>> to appear in transfer lists.  ArrayBuffers that are under objects in
> >>> transfer lists are transferred, others are cloned.
> >>
> >> This again causes the same forwards-compatibility problem.  If you do
> this:
> >>
> >> frame = { video: canvasPixelArrayInstance, histogram: arrayBuffer } }
> >> postMessage({ frame: frame }, { transfer: frame });
> >>
> >> and you expect only histogram to be transferred (since that's all that
> >> supports it when you write this code), your code breaks when
> >> CanvasPixelArray later supports it.
> >>
> >>> b) Transfer lists + separate transferMessage method. We still equip
> >>> postMessage with transfer lists, these transfer lists list
> ArrayBuffers, and
> >>> we provide a separate method transferMessage with recursive transfer
> >>> semantics.
> >>> What do people think?
> >>
> >> Same problem.
> >>
> >> If you want a quicker way to transfer all messages of given types, see
> >> my previous mail: { transfer: ArrayBuffer }.
> >
> > Agreed on these points. Using an object graph for the transfer list
> > (which is what the recursive transfer list idea boils down to) also
> > sounds overly complicated.
> >
> > May I suggest to reconsider adding another optional array argument to
> > postMessage for the transfer list, rather than using an object with
> > special properties?
> >
> > Points in favor of adding another optional array argument:
> >
> > 1. Less typing, and less possibility that a typo will cause incorrect
> behavior:
> >  worker.postMessage(objectGraph, null, [ arrayBuffer1ToTransfer,
> > arrayBuffer2ToTransfer ]);
> >vs.
> >  worker.postMessage(objectGraph, { transfer: [
> > arrayBuffer1ToTransfer, arrayBuffer2ToTransfer] });
> >
> > 2. Possibility of using Web IDL to specify the type of the optional
> > array argument (i.e., "Transferable[]?"). Would be harder to do using
> > an object -- requiring either specifying another interface type with
> > the "ports" and "transfer" attributes, or using "any" plus
> > ECMAScript-specific text.
> >
> > Points in favor of using an object:
> >
> > 1. Could potentially overload the meaning of the optional ports array
> > argument, avoiding adding another argument to postMessage.
> >
> > 2. More extensible in the future.
> >
> > Thoughts?
>
> My first thought is that so far no implementer has stepped up and said
> that changing the meaning of the 'ports' argument would not be
> acceptable. Would be great if someone who is reading this thread and
> who works at Google/Apple/Opera could check with the relevant people
> to see if such a change would be possible.
>

It's certainly possible - there's nothing intrinsically difficult with
making this change from an implementor's point of view (I've had my fingers
in both the WebKit and Chromium MessagePort implementations so I'm
relatively confident that this would not be prohibitively hard).

Is it desirable? My knee-jerk reaction is that we should stick with changes
that are compatible with the existing API (like Ian's original suggestion,
or adding a separate optional array of transferable objects) - I have no
data on the number of sites that are using the current API but I don't think
we should be changing existing APIs with multiple implementations without
significant motivation. The stated motivations for breaking this API don't
seem compelling to me given the existence of backwards-compatible
alternatives.



>
> / Jonas
>
>

Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21

2011-04-20 Thread Andrew Wilson 
On Wed, Apr 20, 2011 at 4:05 PM, Jonas Sicking  wrote:
>
>
> That's why we're working on trying to fix fingerprinting.
>
> The point is that privacy is something that we're all working on
> trying to improve (right?), and the WebWorkers spec needs to be
> changed to aid with that. As far as I can see all that's needed is to
> say that a UA is allowed to not share a worker, and ideally point out
> that such sharing could be disabled when the frame-parent chain
> contains cross origin iframes.
>

Thanks for the clarification, Jonas. So I'm concerned that a blanket
prohibition would break legitimate use cases (iframe-based widgets on a page
communicating with one another). Let's say we have the following:

Top Level Window - http://a.com
Iframe_one - http://b.com
iframe_two - http://b.com

Top Level Window - http://c.com
iframe_three - http://b.com

If iframe_one, two, and three all create the same shared worker, would any
sharing be allowed in the situation you propose? I would at least want
iframe_one and iframe_two to end up referencing a common instance, even if
privacy policy caused iframe_three to get a separate instance because the
top-level window was pointed at c.com instead of a.com.

This seems reasonable to me - I suspect that's what you (and Travis) were
suggesting, but I wasn't positive.

Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21

2011-04-20 Thread Andrew Wilson 
On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. wrote:

>
> Please correct me if I'm missing something, but I don't see any new
> privacy-leak vectors here.  Without Shared Workers, 3rdparty.com can
> just hold open a communication channel to its server and shuttle
> information between the iframes on A.com and B.com that way.


Agreed. Even in the absence of a server, wouldn't those iframes also be able
to communicate via cookies, or localStorage, or any other common data shared
across the domain? I'd be curious about what specific privacy violations
this enables that couldn't already be done in other ways that IE9 does
support?

Also, the PDF you link to describes a DoNotTrack HTTP header/DOM attribute
and a filter list for preventing network access to specific domains - I'm
not certain how either of those pertain to this issue (other than the fact
that said filter lists would equally apply to network connections used from
worker context). Can you provide some clarification of your concerns?