W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: XHR LC comments

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 26 May 2008 14:49:52 +0200
Message-ID: <483AB1F0.6090707@gmx.de>
To: Anne van Kesteren <annevk@opera.com>
CC: "Web API WG (public)" <public-webapi@w3.org>

Anne van Kesteren wrote:
> On Fri, 16 May 2008 13:14:12 +0200, Julian Reschke 
> <julian.reschke@gmx.de> wrote:
>> At this point, I'm not sure why we're bothering with XHR1 at all. It 
>> is *not* what the current implementations do anyway.
> It's setting a baseline for implementations. As with most legacy 
> features without a specification, implementations differ a lot in the 
> details. Typical usage of the API more or less works the same anywhere, 
> but if we only defined that we might as well publish an empty 
> specification and reference some brief description of XMLHttpRequest 
> somewhere on the Web.

That's understood. But what confuses me is the relation to XHR2 -- it 
seems that this WG is splitting time for work on two specs, where just 
working on XHR2 would be more useful.

>>>> Well, if we're talking about URIs (and I think we do), then we need to
>>>> refer to RFC3986 grammar and comparison rules.
>>>  Ok, referenced RFC3986 as well.
>> That's not sufficient, and not what I asked for. Please make up your 
>> mind whether it's a URI or a IRI, and then cite accordingly.
> I deferred this issue to HTML5 for now by referencing the recently 
> introduced definition of "same origin" there. That makes more sense 
> because if any changes to that definition are made there it would also 
> affect XMLHttpRequest.

Pointer, please?

>>>> When they are a string, then taking about character encoding doesn't
>>>> make any sense here.
>>>  Actually, since you need to encode them for the request it does.
>> But that totally depends on the authentication scheme. I think you're 
>> confusing layers here.
> It does depend on that and that is mentioned.

Are you referring to: "14. If the user argument was not omitted and is 
not null let stored user be user  encoded using the encoding specified 
in the relevant authentication scheme or UTF-8 if the scheme fails to 
specify an encoding."?

This has two problems:

- it makes "stored used" an octet sequence, not a string.

- it simply doesn't work in practice, for instance for Basic Authentication

>> How is this relevant for demonstrating the output format for 
>> getAllResponseHeaders()?
> It's relevant in case people copy the example, which I expect to happen. 
> In case they do that and the example would've used synchronous code they 
> end up with UI-lockup et cetera, which would be bad.

Well, we continue to disagree on this point.

The goal for examples should be to illustrate a specific feature, not to 
promote a specific coding practice (at least not when doing the latter 
affects the readability).

BR, Julian
Received on Monday, 26 May 2008 12:50:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:27 UTC