Re: multipart, server-sent events, and

[Robert Sayre]

On Feb 19, 2008 12:20 AM, Mark Baker <[EMAIL PROTECTED]> wrote:
>
> Well, I'd like to see some hard evidence of this before we write it off.

I'd like to see Maciej go first. ;)

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Re: multipart, server-sent events, and

[Mark Baker]

Hi Maciej,

On 2/18/08, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> Last time I looked into this, there were some proxies and some origin
> server configurations (in particular certain Apache modules, perhaps
> now obsolete) that broke with pipelining.

Can you define "broke"?

I've done a search on Apache and Squid pipelining bugs, and didn't
find any open ones.

> Since it is not possible to
> find out from the server if pipelining is correctly supported, and
> since it is not generally possible to tell from the response that it
> has failed, enabling it by default in the browser http stack was not a
> safe thing to do.
>
> Since the breakage is caused in at least some cases by proxies, it is
> not in general safe to let XHR users opt in since they may control the
> origin server but generally would not control whatever proxies are
> between the server and the user.
>
> Pipelining is a great potential performance improvement and it's sad
> that it can't safely be used on the public Internet right now, so I
> hope we someday find a way out of the impasse.

Well, I'd like to see some hard evidence of this before we write it off.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA. http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

Re: multipart, server-sent events, and

[Kris Zyp]

Since the breakage is caused in at least some cases by proxies, it is  not 
in general safe to let XHR users opt in since they may control the  origin 
server but generally would not control whatever proxies are  between the 
server and the user.


Pipelining is a great potential performance improvement and it's sad  that 
it can't safely be used on the public Internet right now, so I  hope we 
someday find a way out of the impasse.


There is a world of difference between browsers choosing to do pipelining 
where no one gets to opt-in, and XHR opt-in where developers know the origin 
server, may even know the full route for all users (as in intranets) and can 
make the calculating risk of where they want to try pipelining or not, and 
can even code backup solutions when pipelined requests fail. It seems very 
presumptious to tell developers that can't take that risk. Why not tell them 
they can't use XHR at all, since there are old browsers out there don't 
support XHR? Because developers should be given the opportunity to make this 
decision. Developers have chosen to use XHR even though there are browsers 
that don't support it, and this has led to progress. If they experience too 
much pipelining failure they can choose to opt-out. I am very skeptical that 
at this point the failure rate is high enough that very many developers 
would opt-out.
Ironically, this is probably our best opportunity to get through this 
impasse. If web developers can selectively turn on XHR, the few remaining 
proxies out there that break under pipelining will start to be singled out, 
and more likely to be fixed which in turn will create the pipeline 
reliability for browsers to use it more broadly.
Kris 

Re: multipart, server-sent events, and

[Maciej Stachowiak]

On Feb 15, 2008, at 2:09 PM, Mark Baker wrote:



On 2/14/08, Kris Zyp <[EMAIL PROTECTED]> wrote:


Another functionality that I believe would be extremely valuable to  
expose
for XHR would be HTTP pipelining control. Most browsers do not  
provide HTTP
pipelining because of compatibility concerns and performance  
implications of

improperly order requests.


I thought it was just that most proxies don't support it on the
outbound connection.  And I've never seen any ordering problems from
the support, or lack thereof, of pipelining.

But I certainly agree that pipelining control would be really useful.


Last time I looked into this, there were some proxies and some origin  
server configurations (in particular certain Apache modules, perhaps  
now obsolete) that broke with pipelining. Since it is not possible to  
find out from the server if pipelining is correctly supported, and  
since it is not generally possible to tell from the response that it  
has failed, enabling it by default in the browser http stack was not a  
safe thing to do.


Since the breakage is caused in at least some cases by proxies, it is  
not in general safe to let XHR users opt in since they may control the  
origin server but generally would not control whatever proxies are  
between the server and the user.


Pipelining is a great potential performance improvement and it's sad  
that it can't safely be used on the public Internet right now, so I  
hope we someday find a way out of the impasse.


Regards,
Maciej

Re: multipart, server-sent events, and

[Mark Baker]

On 2/15/08, Kris Zyp <[EMAIL PROTECTED]> wrote:
> > Would you be able to write this up as a concrete proposal for
> > additions to one or both of the existing XHR spec or the (TBD) XHR2
> > spec?
>
> Yes. Are you referring specifically to pipelining, or other matters
> discussed? Either I will do that.

Potentially everything we discussed.  It's up to you.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA. http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

[selectors-api] No comments from CSS WG

[Bert Bos]

Hello WebAPI WG,

The CSS WG has no comments on the Selectors API draft.



For the CSS WG,
Bert
-- 
  Bert Bos( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos   W3C/ERCIM
  [EMAIL PROTECTED] 2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 9206902 Sophia Antipolis Cedex, France

Fwd: Re: [css3-namespaces] upcoming last call for the CSS3 Namespaces Module

[Charles McCathieNevile]

FYI.

If anyone thinks we should comment as a group, please say so and we will  
look at the comments (and get an extension if necessary to ensure that we  
make comments we agree on)


cheers

Chaals

--- Forwarded message ---
From: "Bert Bos" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: "Hypertext CG" <[EMAIL PROTECTED]>
Subject: Re: [css3-namespaces] upcoming last call for the CSS3 Namespaces  
Module

Date: Sat, 16 Feb 2008 00:04:59 +0100

The draft has now been published and the deadline for comments has been
set to March 7:

 http://www.w3.org/TR/2008/WD-css3-namespace-20080215



Bert



--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Re: [comments] Selectors-API

[Lachlan Hunt]

Addison Phillips wrote:

3. Add Unicode normalization as a requirement.

The I18N WG notes that comparison of namespace prefixes, in order to be 
reliable, require Unicode Normalization Form C. For more information, 
see CharModNorm [2].


This specification cannot require the NSResolver object to perform 
Unicode Normalisation.  The NSResolver object is defined as a black box 
in that only the input and expected output is defined.  The internal 
processing, where string comparisons would be performed, is left 
entirely up to the implementer.  This is because, as previously 
explained, the resolver is expected to be implemented by application 
developers (especially JavaScript developers), not user agents, and it 
would be unrealistic to expect such developers to adhere to the requirement.


Therefore, the only other possible alternative would be to require the 
user agent to perform normalisation of the selector before invoking and 
passing the normalised prefix to the resolver.  However, the rules for 
the processing of selectors is delegated to the Selectors specification, 
which, AFAICT, does not require normalisation to occur.  In practice, 
browsers do not perform normalisation of selectors in CSS either and 
comparison is performed using non-normalised strings.


If this specification were to require normalisation of selectors itself, 
it would create an incompatibility between selectors as used in CSS, and 
as used in these APIs.  Such incompatibility is not acceptable.


For normalisation to occur, it would require the CSS WG to address the 
issue in the Selectors specification, and for browser vendors to 
implement it for both CSS and these APIs, and any other affected 
languages.  It would also require implementers of the NSResolver objects 
to expect prefixes to be passed in normalised form, which would 
potentially increase the complexity of NSResolver implementations, where 
prefixes containing affected characters are used.


No change has been made to the specification in regards to this issue. 
Please let me know if you are not satisfied with this response.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [XHR] Editorial - labelling sections

[Anne van Kesteren]

On Mon, 18 Feb 2008 11:50:59 +0100, Charles McCathieNevile  
<[EMAIL PROTECTED]> wrote:
You mean in the source? If so, putting in an expanded table of contents  
somewhere that links in more detail, so I could see and copy/paste the  
relevant link without reading the source would be extremely helpful.


There are links from the IDL block.


--
Anne van Kesteren

Re: [XHR] Editorial - labelling sections

[Charles McCathieNevile]

On Wed, 13 Feb 2008 01:28:46 +0100, Anne van Kesteren <[EMAIL PROTECTED]>  
wrote:


On Tue, 12 Feb 2008 20:01:30 +0100, Charles McCathieNevile  
<[EMAIL PROTECTED]> wrote:
working through the first test case I looked at, sections of the  
document seem to be quite large. I believe it would be helpful if there  
were a more granular breakdown of sections, and a more detailed table  
of contents, in order to refer in more detail to important parts of the  
spec.


This is changed in XMLHttpRequest Level 2. I rather not change the whole  
structure for XMLHttpRequest Level 1 as we've had this structure since  
the beginning and changing it will be quite some editorial work with a  
high risk of introducing errors. Each member of the interface has a  
unique identifier so you can easily point to them.


You mean in the source? If so, putting in an expanded table of contents  
somewhere that links in more detail, so I could see and copy/paste the  
relevant link without reading the source would be extremely helpful.


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com