Re: UMP / CORS: Implementor Interest

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'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.

Cheers,
Maciej

Received on Tuesday, 20 April 2010 18:47:40 UTC