Re: UMP / CORS: Implementor Interest

On Tue, Apr 20, 2010 at 11:47 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Apr 20, 2010, at 11:34 AM, Jonas Sicking wrote:
>
>> On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren <annevk@opera.com>
>> wrote:
>>>
>>> On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking <jonas@sicking.cc>
>>> wrote:
>>>>
>>>> As I've said before. I'd be interested in implementing UMP in firefox
>>>> if we can come  up with a reasonable API for using it. I.e. a separate
>>>> constructor or flag or similar on XHR. This is assuming that UMP is a
>>>> reasonable subset of CORS.
>>>
>>> Have you looked at the proposal I put in XHR2? It sets certain flags in
>>> CORS
>>> that make it more or less the same as UMP. I don't really see why we
>>> would
>>> need UMP if we have that.
>>
>> It looks ok to me, though somewhat lacking on details. What happens if you
>> call
>>
>> x = new XMLHttpRequest("foopy");
>> or
>> x = new XMLHttpRequest(undefined);
>>
>>
>> You should probably define that the 'anon' argument is a boolean so
>> that the normal conversion rules automatically are applied.
>
> I kinda hate the boolean argument. I would rather have a syntax where the
> intent is obvious from the source code. A boolean is not very
> self-documenting. In fact I can't even remember right now whether true or
> false is the value that gives you anonymous XHR. Possibilities:
>
> - Separate AnonXMLHttpRequest constructor
> - Constructor parameter takes an enum value, so you write new
> XMLHttpRequest(ANON) or something like that.
> - Constructor parameter takes a string value, so you write new
> XMLHttpRequest("anon") or ("anonymous") or whatever.
>
> For any of those options (or similar variants), it would be immediately
> obvious from source what is going on.

I agree that these all are better options. I think I like the enum one
the least, especially since you'd likely have to write

x = new XMLHttpRequest(XMLHttpRequest.ANON);

which would likely result in people writing

x = new XMLHttpRequest(1);

My favorite is the separate constructor.

>> I'm also wondering if the UMP guys are happy with this syntax.
>>
>>>> There has been suggestions of changing header names. I'm not a big fan
>>>> of the current names, but if we're going to fix them, i'd rather see a
>>>> coherent strategy for all CORS headers than random spot fixes.
>>>
>>> Does that mean you would be willing to remove support for the current
>>> header
>>> names? If not I'm not sure if it is worth it. But if you are I will make
>>> a
>>> proposal.
>>
>> Yeah, the goal would definitely be to drop the old header names. We
>> probably couldn't drop them right away, but would need a phase-out
>> period. I think this would still be doable, but the longer we wait the
>> less that is going to be true.
>>
>> Also, it requires everyone to be on board with this change, including
>> webkit and Microsoft.
>
> What do we know about the current level of CORS deployments? I'd be very
> hesitant to change headers that are actively in use. It might be reasonable
> to change only some of the headers if we learn that, for example,
> "Access-Control-Allow-Origin" is the only one in common use.
>
> Also, it's hard to answer this in the hypothetical. Do we have a specific
> idea for new header names that would be really great? I'm worried that
> opening up for change will just trigger a giant bikeshed and possibly not
> result in better names in the end.

These are all good questions. I'd say the responsibility to suggest
better names lies with the people that want to change the current
names.

I think phasing out the existing header names could be done relatively
quickly. The one exception is IE which traditionally have been slower
moving as far as backwards incompatible changes goes.

I don't intend to spend a lot of time on this until someone has
suggested a new set of header names and gotten microsoft to say they
are fine with implementing them in XDR.

/ Jonas

Received on Tuesday, 20 April 2010 19:03:12 UTC