For the record, I'm perfectly happy with WebSockets not being made any more
complicated for v1 (i.e. no multi-plexing), but I don't think your arguments
against it are compelling at all, so I'm going to play devils advocate:
On Fri, Sep 4, 2009 at 2:37 PM, Ian Hickson i...@hixie.ch wrote:
I'd like to propose that HTML5 specify different schemes than a
conceptual global storage mutex to provide consistency guarantees for
localStorage and cookies.
Cookies would be protected according to Benjamin Smedberg's post in the
[whatwg] Storage mutex and cookies can lead to browser
On Fri, Sep 4, 2009 at 4:02 PM, Chris Jones cjo...@mozilla.com wrote:
I'd like to propose that HTML5 specify different schemes than a conceptual
global storage mutex to provide consistency guarantees for localStorage and
cookies.
Cookies would be protected according to Benjamin Smedberg's
Ian Hickson wrote:
On Fri, 14 Aug 2009, Jeremy Orlow wrote:
On Fri, Aug 14, 2009 at 3:45 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 7 Aug 2009, Jonas Sicking wrote:
What would the API look like?
It seems like it could be done transparently to the web developer. If
you open 2
On Fri, 04 Sep 2009 09:02:45 +0200, Chris Jones cjo...@mozilla.com wrote:
Feedback very much desired.
I'm not really sure what to say other than that I'm not at all a fan of a
change that breaks existing deployments. I thought that was a pretty clear
outcome from last time we went about
Justin Lebar wrote:
Mike Wilson wrote:
The result is that the address bar URL can't be trusted, as
any page on the site can impersonate any other without
consent from that page or part of the site?
Someone will correct me if I'm wrong, but I think this is already
pretty much the case
On Tue, 1 Sep 2009, Edward O'Connor wrote:
From #attr-time-pubdate:
If specified, [pubdate=] indicates that the date and time given by
the element is the publication date and time of the nearest ancestor
article element. If the element has no ancestor article element, the
pubdate
Interesting. I've been following this discussion as my
experience is that it is *extremely* hard to make an
invisible locking mechanism that is to provide both
consistency and performance (no lockouts).
So far it seems a silver bullet hasn't been found.
Your suggestion is in line with what I
On Fri, 04 Sep 2009 02:44:25 +0200, Oliver Hunt oli...@apple.com wrote:
On Sep 3, 2009, at 4:50 PM, Robert O'Callahan wrote:
On Fri, Sep 4, 2009 at 4:48 AM, Oliver Hunt oli...@apple.com wrote:
On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote:
Yeah, that seems likely, since none of you
Ian Hickson wrote:
...
If you're looking for something, start at the start. Don't try to
short-circuit the spec and jump half-way through your answer; if you do
that you might miss restrictions that apply to particular cases.
...
At the start of the spec? Seriously?
BR, Julian
On Thu, Sep 3, 2009 at 4:40 PM, Simon Pieterssim...@opera.com wrote:
On Thu, 03 Sep 2009 18:23:37 +0200, Alex Henrie alexhenri...@gmail.com
wrote:
On Thu, Sep 3, 2009 at 1:29 AM, Smylerssmyl...@stripey.com wrote:
Like other compatibility mode behavior, implementation would be
voluntary and
Jeremy Orlow wrote:
I mostly agree with your assertions about the type of developer who's
using localStorage. It sure would be nice if we could give developers
powerful APIs and keep them simple and make it possible to implement
them in a performant manner. Unfortunately, I think the current
Mike Wilson wrote:
Interesting. I've been following this discussion as my
experience is that it is *extremely* hard to make an
invisible locking mechanism that is to provide both
consistency and performance (no lockouts).
So far it seems a silver bullet hasn't been found.
Your suggestion is
On Sep 3, 2009, at 6:05 PM, Francisco Tolmasky wrote:
However, I think the addition of the deferred setData methods could
be added today in a way that is completely backwards compatible with
current implementations and would still be of great benefit.
Specifically, my request for
On Wed, 2 Sep 2009, Jens Alfke wrote:
On Sep 1, 2009, at 6:35 PM, Ian Hickson wrote:
Right now this can be done by the site directly.
You mean a download link I can click? Sure, but then the site has no
ability to access that data later unless I explicitly locate the file
and upload
On Fri, Sep 4, 2009 at 9:44 PM, Jeremy Orlow jor...@chromium.org wrote:
I think it's pretty clear that the spec, as is, is not possible to
implement without making it trivial for a single website to lock up all of
your event loops
I don't think that's clear at all, yet.
It's clearly
On Fri, 04 Sep 2009 20:07:19 +0200, Alex Henrie alexhenri...@gmail.com
wrote:
Whether or not you implement hacks for poorly designed router
firmwares as you have done for other sites is entirely up to you.
IE and Opera recognize that some web pages, in particular someold router
firmwares,
On Wed, 2 Sep 2009, Dirk Pranke wrote:
In testing various combinations of attributes on textareas, I've found a
couple of inconsistencies and some vagueness in the spec.
1) The wrap=hard attribute appears to be defined such that you get
hard line breaks at the specified character width
On Wed, 2 Sep 2009, Aryeh Gregor wrote:
On Wed, Sep 2, 2009 at 6:17 PM, Ian Hicksoni...@hixie.ch wrote:
The user agent stops fetching the media data before it is completely
downloaded implies that 1) it cannot occur after the media is
completely downloaded,
Correct.
Okay, then I was
On Thu, Sep 3, 2009 at 7:41 AM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 31 Aug 2009, Jonas Sicking wrote:
Upon further consideration I've renamed getStorageUpdates() to
yieldForStorageUpdates().
'yield' usually refers to halting execution. I would expect the above
name to stop the
Robert O'Callahan wrote:
On Fri, Sep 4, 2009 at 9:44 PM, Jeremy Orlow jor...@chromium.org
mailto:jor...@chromium.org wrote:
I think it's pretty clear that the spec, as is, is not possible to
implement without making it trivial for a single website to lock up
all of your event
On Fri, Sep 4, 2009 at 1:45 AM, Ian Hicksoni...@hixie.ch wrote:
On Fri, 14 Aug 2009, Jonas Sicking wrote:
How do you envisage multiplexing working? It's not clear to me what we
could do that would be easier to handle than just having the script
manually do the multiplexing at the
On Thu, 3 Sep 2009, Aryeh Gregor wrote:
In 4.9.11:
The rowSpan DOM attribute must reflect the content attribute of the
same name. Its default value, which must be used if parsing the
attribute as a non-negative integer returns an error, is also 1.
What does also refer to?
Nothing,
While the concerns on the server-side are overstated, the analogy to http is
also questionable ... The current protocol, being a *scoket* layer protocol,
is in principle different than http, which is strictly a L7 RPC protocol.
Is there any fundamental limitation for different UI components to
re: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-40
1) section 6: User agents should not close the Web Socket connection
arbitrarily.
Please clarify what arbitrarily means .. given there is no handshake for
close?
2) section 7: Servers that only accept input from one origin can
25 matches
Mail list logo
