W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: UMP / CORS: Implementor Interest

From: Dirk Pranke <dpranke@chromium.org>
Date: Wed, 21 Apr 2010 14:43:28 -0700
Message-ID: <o2q3726d1bf1004211443p922605d2pf70ae35f33b73490@mail.gmail.com>
To: Tyler Close <tyler.close@gmail.com>
Cc: Ojan Vafai <ojan@chromium.org>, Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>, "public-webapps@w3.org" <public-webapps@w3.org>
On Wed, Apr 21, 2010 at 1:49 PM, Tyler Close <tyler.close@gmail.com> wrote:
> On Wed, Apr 21, 2010 at 1:29 PM, Ojan Vafai <ojan@chromium.org> wrote:
>> I've been watching the CORS/UMP debate from the sidelines. Here's how it
>> looks to me:
>> 1) UMP folk want to keep UMP a separate spec so that it can (theoretically)
>> be easier to implement and ship sooner.
>
> We want to keep it a separate specification for two main reasons:
> a) The simpler, shorter UMP spec is easier for web developers to
> understand than a combined spec would be.
> b) We believe there are significant technical issues with CORS that
> should prevent it from being standardized in its current form.
>
> I suspect implementation of UMP features is independent of whether or
> not there are two documents or one, or whether its called CORS or
> UMP/CORS. I suspect implementers will move ahead if they think it's a
> good idea with a stable specification. For example, I don't think the
> number of documents used to specify the formerly more monolithic HTML5
> has affected implementation plans.
>
>> 2) Browser vendors intend to implement CORS. They don't want to have two
>> similar but slightly different stacks for making requests, either in
>> implementation or in what's exposed to developers. So, having UMP as a
>> separate spec doesn't make sense if it's intended to be a subset (or even
>> mostly a subset) of CORS. Mozilla might be willing to implement UMP with
>> some API modifications and Microsoft hasn't voiced an opinion.
>> Is that an accurate summary?
>> Are there other advantages to keeping UMP a separate spec other than
>> concerns of ship dates? Given the lack of vendor support, it doesn't seem
>> like ship date is really a good argument since the ship date is dependent
>> on vendors actually implementing this.
>
> AFAICT, there is good implementer support for the technical features
> defined in UMP. Both Maciej and Anne indicated the features might be
> implemented, but under the name CORS rather than UMP. AFAICT, that
> constraint can be met by having CORS reference and extend UMP.
>

I believe UMP suffers from the perception that it is Yet Another Spec,
as in some people will look at it and think "we're already doing CORS,
why do we need to implement Yet Another Spec"? Whatever you can do to
fix that impression will be in your interest.

Similarly, if it is really your intent to stop CORS from getting
implemented, you're going to have to sell that harder, because (to
switch metaphors), if that ship hasn't already sailed, it is at least
boarding.

-- Dirk

(Not speaking on behalf of the Chromium team)
Received on Wednesday, 21 April 2010 21:44:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT