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
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
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
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
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
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
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
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
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
.
-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
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
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
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
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
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
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)
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
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
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
19 matches
Mail list logo
