Re: Two years on and still no sensible web storage solutions exist
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 pya...@gmail.com 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 toddvblanch...@gmail.comwrote: 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: Two years on and still no sensible web storage solutions exist
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 pya...@gmail.com wrote: On Mon, Nov 12, 2012 at 3:49 PM, Kyle Huey m...@kylehuey.com 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: Sync API for workers
On Sat, Sep 1, 2012 at 2:32 PM, Glenn Maynard gl...@zewt.org wrote:
On Sat, Sep 1, 2012 at 3:19 PM, Rick Waldron waldron.r...@gmail.comwrote:
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 olli.pet...@helsinki.fiwrote:
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: Sync API for workers
On Sun, Sep 2, 2012 at 12:16 PM, Glenn Maynard gl...@zewt.org wrote: On Sun, Sep 2, 2012 at 12:24 PM, Andrew Wilson atwil...@google.comwrote: 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: Web Notifications
On Wed, Jun 20, 2012 at 3:17 AM, Olli Pettay olli.pet...@helsinki.fi 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: Web Notifications
On Wed, Jun 20, 2012 at 2:36 PM, Andrew Wilson atwil...@google.com wrote: On Wed, Jun 20, 2012 at 3:17 AM, Olli Pettay olli.pet...@helsinki.fi 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: Shared workers - use .source instead of .ports[0] ?
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 jo...@sicking.cc wrote: On Tue, Apr 10, 2012 at 10:44 PM, David Levin le...@google.com 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] ?
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 sim...@opera.com wrote: On Wed, 11 Apr 2012 09:29:53 +0200, Jonas Sicking jo...@sicking.cc 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] ?
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 sim...@opera.com wrote:
On Tue, 10 Apr 2012 14:01:47 +0200, Jarred Nicholls jar...@webkit.org
wrote:
On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters sim...@opera.com wrote:
On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking jo...@sicking.cc
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] ?
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 atwil...@google.com 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 sim...@opera.com wrote:
On Tue, 10 Apr 2012 14:01:47 +0200, Jarred Nicholls jar...@webkit.org
wrote:
On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters sim...@opera.com wrote:
On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking jo...@sicking.cc
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] ?
On Tue, Apr 10, 2012 at 1:06 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Apr 10, 2012 at 10:47 AM, Andrew Wilson atwil...@google.com 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: Opening discussion on StreamWorker
On Thu, Nov 17, 2011 at 7:30 PM, Charles Pritchard ch...@jumis.com 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.jshttp://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]
On Wed, Jun 22, 2011 at 2:31 AM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jun 22, 2011 at 4:33 AM, David Levin le...@chromium.org 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]
On Wed, Jun 8, 2011 at 6:26 PM, Kenneth Russell k...@google.com 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]
On Thu, Jun 9, 2011 at 11:13 AM, Glenn Maynard gl...@zewt.org wrote: On Thu, Jun 9, 2011 at 1:28 PM, Andrew Wilson atwil...@google.com 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]
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell k...@google.com wrote:
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov dslo...@google.com
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: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Fri, Jun 3, 2011 at 3:23 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson atwil...@google.com 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: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: 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?
Re: Reminder: RfC: Last Call Working Draft of Web Workers; deadline April 21
On Wed, Apr 20, 2011 at 4:05 PM, Jonas Sicking jo...@sicking.cc 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.
