On Fri, 29 Jul 2011, Takeshi Yoshino wrote:
While conducting such experiments, user-agents are not standard
compliant. If W3C/WHATWG are confident that violating specs is the right
way to evolve specs, I'll stop arguing this. Yes, we'll make our
browsers standard non-compliant to seek the
Is new XHR spec going to make gzip mandatory for its underlying HTTP?
On Tue, Jul 26, 2011 at 06:05, Aryeh Gregor simetrical+...@gmail.comwrote:
From the discussion here, it sounds like there are problems with
WebSockets compression as currently defined. If that's the case, it
might be
On Wed, 27 Jul 2011 03:35:03 -0700, Takeshi Yoshino tyosh...@google.com
wrote:
Is new XHR spec going to make gzip mandatory for its underlying HTTP?
I do not think that analogy makes sense. The WebSocket protocol can only
be used through the WebSocket API, HTTP is prevalent in more places.
On Thu, Jul 28, 2011 at 00:06, Anne van Kesteren ann...@opera.com wrote:
On Wed, 27 Jul 2011 03:35:03 -0700, Takeshi Yoshino tyosh...@google.com
wrote:
Is new XHR spec going to make gzip mandatory for its underlying HTTP?
I do not think that analogy makes sense. The WebSocket protocol can
On Wed, 27 Jul 2011 08:49:57 -0700, Takeshi Yoshino tyosh...@google.com
wrote:
What do you mean by more places?
XMLHttpRequest is not the sole API for HTTP, there's also a, form,
etc. So indicating what parts of the HTTP protocol are mandatory for
browsers is not really in scope for
On Thu, Jul 28, 2011 at 02:03, Anne van Kesteren ann...@opera.com wrote:
On Wed, 27 Jul 2011 08:49:57 -0700, Takeshi Yoshino tyosh...@google.com
wrote:
What do you mean by more places?
XMLHttpRequest is not the sole API for HTTP, there's also a, form, etc.
So indicating what parts of the
On Wed, 27 Jul 2011 11:04:09 -0700, Takeshi Yoshino tyosh...@google.com
wrote:
So, let me correct my text by s/XHR/HTML5 http://www.w3.org/TR/html5//.
HTML5 is mostly transport-layer agnostic.
I am not sure why we are going through this theoretical side-quest on
where we should state what
We are talking about it at IETF81 this week.
That said, I think either way browsers should not require deflate-stream. I
am hoping we can make forward progress on deflate-application-data (
http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01).
If we can get that through
On Wed, Jul 27, 2011 at 1:12 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote:
We are talking about it at IETF81 this week.
That said, I think either way browsers should not require deflate-stream. I
am hoping we can make forward progress on deflate-application-data (
I don't think we want to forbid any extensions. The whole point of
extensions is to allow people to do something that doesn't necessarily have
consensus by a broad enough group to be in the base protocol. That said, I
think a lot of people would be happier if deflate-stream were an independent
On Wed, Jul 27, 2011 at 3:14 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote:
I don't think we want to forbid any extensions.
At the protocol level, sure. At the API level we have to pick which
functionality user agents are required to support and which they are
required not to support, having
I agree we shouldn't require deflate-stream it in the API. I don't agree the
API should specify an exact set of extensions, as that would prevent any
future versions/developments. A minimum baseline would be reasonable though,
once we have that minimum baseline in place (e.g. a stable set of
On Wed, 27 Jul 2011 15:31:28 -0700, Ian Fette (イアンフェッティ)
ife...@google.com wrote:
I agree we shouldn't require deflate-stream it in the API. I don't agree
the API should specify an exact set of extensions, as that would prevent
any
future versions/developments. A minimum baseline would be
On Wed, 27 Jul 2011, Ian Fette (�~B��~B��~C��~C~U�~B��~C~C�~C~F�~B�) wrote:
I agree we shouldn't require deflate-stream it in the API. I don't agree
the API should specify an exact set of extensions, as that would prevent
any future versions/developments. A minimum baseline would be
On 27 July 2011 20:35, Takeshi Yoshino tyosh...@google.com wrote:
(a) it's not acceptable to make support (== request) of good-compression
optional
I understand the desire to make good compression universal, but I'm
not sure that making it a required part of the specification is the
way to go.
On 7/25/11 5:05 PM, ext Aryeh Gregor wrote:
From the discussion here, it sounds like there are problems with
WebSockets compression as currently defined.
Yes, this is what I have concluded too (and if we are wrong, I would
appreciate it if someone on the hybi list would please clarify).
On Thu, Jul 21, 2011 at 1:02 PM, Adrian Bateman adria...@microsoft.com wrote:
For platform features that directly affect web developers' pages that might
sometimes be true. However, compression is also optional in HTTP and it
doesn't appear to have caused problems or made some sites work and
On Monday, July 25, 2011 1:32 PM, Aryeh Gregor wrote:
On Thu, Jul 21, 2011 at 1:02 PM, Adrian Bateman adria...@microsoft.com
wrote:
For platform features that directly affect web developers' pages that might
sometimes be true. However, compression is also optional in HTTP and it
doesn't
On Mon, Jul 25, 2011 at 4:58 PM, Adrian Bateman adria...@microsoft.com wrote:
First, I don't think that's the same thing at all.
Why not?
Second, the IETF HyBi working
group has asked members of this working group for Last Call feedback. If you
think the protocol has the wrong mix of
Resending. I've made mistake in processing public-webapps@w3.org confirmation
page.
On Fri, Jul 22, 2011 at 19:45, Takeshi Yoshino tyosh...@google.com wrote:
On Fri, Jul 22, 2011 at 18:54, Anne van Kesteren ann...@opera.com wrote:
On Fri, 22 Jul 2011 07:03:34 +0200, Takeshi Yoshino
On 22 July 2011 03:16, Anne van Kesteren ann...@opera.com wrote:
On Thu, 21 Jul 2011 19:02:31 +0200, Adrian Bateman adria...@microsoft.com
wrote:
For platform features that directly affect web developers' pages that
might sometimes be true. However, compression is also optional in HTTP and
On Fri, 22 Jul 2011 07:03:34 +0200, Takeshi Yoshino tyosh...@google.com
wrote:
Think of these facts, the only dominant implementation concern I can
come up with for WebSocket compression is that big service provides may
take an aggressive policy that they require users to use only WebSocket
Bug 12917 [1] has been discussed in at least bugzilla as well as e-mail
including this thread started by Adrian (Hixie's follow-up is [2]) and
Adrian's general Web Sockets LC thread [3].
This bug is currently resolved as WontFix and this resolution is
supported by at least Hixie and Jonas.
On Thu, 21 Jul 2011 17:26:21 +0200, Arthur Barstow art.bars...@nokia.com
wrote:
What do others (Anne?, Maciej?, ...) think about this issue?
I don't know enough about the WebSocket protocol, but optional web
platform features suck. They will become mandatory following the typical
dominant
On Thu, 21 Jul 2011, Arthur Barstow wrote:
Given the Protocol is now in LC review, it seems relatively important to
align the API and Protocol.
The API and the protocal _are_ aligned. The protocol asks for the consumer
to provide a list of extensions. Nothing in the protocol requires that
On Thursday, July 21, 2011 8:31 AM, Anne van Kesteren wrote:
On Thu, 21 Jul 2011 17:26:21 +0200, Arthur Barstow art.bars...@nokia.com
wrote:
What do others (Anne?, Maciej?, ...) think about this issue?
I don't know enough about the WebSocket protocol, but optional web
platform features
On Thu, 21 Jul 2011 19:02:31 +0200, Adrian Bateman
adria...@microsoft.com wrote:
For platform features that directly affect web developers' pages that
might sometimes be true. However, compression is also optional in HTTP
and it
doesn't appear to have caused problems or made some sites work
On Thu, 21 Jul 2011, Adrian Bateman wrote:
For platform features that directly affect web developers' pages that
might sometimes be true. However, compression is also optional in HTTP
and it doesn't appear to have caused problems or made some sites work
and others not based on some
On Thursday, July 21, 2011 12:33 PM, Ian Hickson wrote:
On Thu, 21 Jul 2011, Adrian Bateman wrote:
For platform features that directly affect web developers' pages that
might sometimes be true. However, compression is also optional in HTTP
and it doesn't appear to have caused problems
Ian,
I understand this point of view. That said, there is a lot of disagreement
in the IETF WG about deflate-stream. The extension basically breaks all
other extensions, framing, etc. It's a bit of a mess and a lot of us want to
just yank it out entirely. There was a much better proposal by
On Thu, 21 Jul 2011, Ian Fette (�~B��~B��~C��~C~U�~B��~C~C�~C~F�~B�) wrote:
I understand this point of view. That said, there is a lot of
disagreement in the IETF WG about deflate-stream. The extension
basically breaks all other extensions, framing, etc. It's a bit of a
mess and a lot of
On Thu, 21 Jul 2011, Adrian Bateman wrote:
On Thursday, July 21, 2011 12:33 PM, Ian Hickson wrote:
On Thu, 21 Jul 2011, Adrian Bateman wrote:
For platform features that directly affect web developers' pages
that might sometimes be true. However, compression is also optional
in
On Fri, 8 Jul 2011, Adrian Bateman wrote:
I strongly disagree. We must have interoperability amongst browser
user agents. Having some support compression and others not would lead
to authoring mistakes and will force us into either having or not
having compression based on how big
33 matches
Mail list logo
