On 6/24/13 5:49 PM, Ehsan Akhgari wrote:
What about changes made in order to improve compliance with a spec not
developed by Mozilla?
This is a tough call. My experience is that most specs out there are
buggy in their use of WebIDL and in their general API design, so such a
change would need
On 6/21/13 1:45 PM, Andrew Overholt wrote:
Back in November, Henri Sivonen started a thread here entitled
"Proposal: Not shipping prefixed APIs on the release channel" [1]. The
policy of not shipping moz-prefixed APIs in releases was accepted AFAICT.
I've incorporated that policy into a broader
Hi Andrew,
Below is a review of the document. I've included the text and responded inline…
On Sunday, 7 July 2013 at 15:24, Marcos Caceres wrote:
> Guidelines
>
> Mozilla aims to advance the state of the open web with new APIs. Toward this
> end,
>
> Mozilla will not hurt the web by expo
Thank you to everyone that provided feedback. I've read everyone's
comments and taken them into account with my new draft:
https://wiki.mozilla.org/User:Overholt/APIExposurePolicy
In general I tried to make it more of a set of requests and guidelines
than a set of "must"s. I also clarified
On Wednesday, July 3, 2013 at 12:16 PM, Robert O'Callahan wrote:
> On Wed, Jul 3, 2013 at 11:06 PM, Marcos Caceres (mailto:mcace...@mozilla.com)> wrote:
> > On Wednesday, June 26, 2013 at 11:33 PM, Robert O'Callahan wrote:
>
>
> I'd like someone with experience implementing and maintaining AP
On Wed, Jul 3, 2013 at 11:06 PM, Marcos Caceres wrote:
> On Wednesday, June 26, 2013 at 11:33 PM, Robert O'Callahan wrote:
> > I think we should try. So, we should try to have someone carve out some
> > time to review Web MIDI, at least to the point where we feel confident it
> > would make sense
On Wednesday, June 26, 2013 at 11:33 PM, Robert O'Callahan wrote:
> I think we should try. So, we should try to have someone carve out some
> time to review Web MIDI, at least to the point where we feel confident it
> would make sense to implement.
I've been heavily involved with Web MIDI for a
Don't forget to add your prefixed API's/properties to this meta bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=775235
We've been very active in getting rid of prefixes as quickly as we can. I love
that CSS Flexbox shipped unprefixed after testing with an about:config flag for
several cycles.
On 26/06/13 18:27, Ehsan Akhgari wrote:
2. ecosystem- and hardware-specific APIs that are not standard or of
interest to the broader web at that time (or ever) may be shipped in
a way to limit their harm of the broader web (ex. only on a device
or only in specific builds with c
On 26/06/13 17:08, Andrew Overholt wrote:
> On 25/06/13 12:15 PM, Mounir Lamouri wrote:
>> Also, I do not understand why we are excluding CSS, WebGL and WebRTC. We
>> should definitely not make this policy retro-apply so existing features
>> should not be affected but if someone wants to add a new
On Jun 26, 2013 7:33 PM, "Ehsan Akhgari" wrote:
>
> On 2013-06-25 9:02 PM, Jonas Sicking wrote:
>>
>> "For new products, APIs that have not yet been embraced by other
>> vendors or thoroughly discussed by standards bodies may be shipped
>> only as a part of this product. Standardization must howev
On 26/06/13 18:13, Ehsan Akhgari wrote:
> On 2013-06-26 12:17 PM, Andrew Overholt wrote:
>> On 26/06/13 11:48 AM, Ehsan Akhgari wrote:
>>> On 2013-06-26 11:21 AM, Andrew Overholt wrote:
On 24/06/13 05:52 PM, Ehsan Akhgari wrote:
> There are two things that I think can use clarification. O
On 26/06/13 16:59, Ehsan Akhgari wrote:
> For whatever it's worth, Blink has made the decision to implement Web
> MIDI without receiving any feedback from us (and to the best of my
> knowledge from other vendors),
I am not sure why implementing something should require that many rules
as long as i
On Thu, Jun 27, 2013 at 3:59 AM, Ehsan Akhgari wrote:
> On 2013-06-26 9:09 AM, Robert O'Callahan wrote:
>
>> If we think these use cases are (or ever will be) relevant, we need to
>> give
>> feedback even if we don't plan to implement them soon. We should at least
>> try to make sure these APIs ar
On Wed, Jun 26, 2013 at 2:07 PM, Gavin Sharp wrote:
> The scope of the current proposal is what's being debated; I don't think
> there's shared agreement that the scope should be "detectable from web
> script".
>
>
Partially embedded in this discussion is the notion that the open web
requires coo
The scope of the current proposal is what's being debated; I don't think
there's shared agreement that the scope should be "detectable from web
script".
Gavin
On Wed, Jun 26, 2013 at 11:01 AM, Ehsan Akhgari wrote:
> On 2013-06-26 1:38 PM, Gavin Sharp wrote:
>
>> The message you quote has a spec
On 2013-06-26 1:38 PM, Gavin Sharp wrote:
The message you quote has a specific example - "Mozillians who have
experience designing JS APIs and will have at least one representative
from the JS team at all times" is probably not the best group to
determine whether we should implement support for/s
The message you quote has a specific example - "Mozillians who have
experience designing JS APIs and will have at least one representative
from the JS team at all times" is probably not the best group to
determine whether we should implement support for/ship SPDY, for
example. I think it's clear th
On 2013-06-25 9:02 PM, Jonas Sicking wrote:
"For new products, APIs that have not yet been embraced by other
vendors or thoroughly discussed by standards bodies may be shipped
only as a part of this product. Standardization must however start
within X months after shipping initial version of the
On 2013-06-26 12:08 PM, Andrew Overholt wrote:
"ship" is too restrictive. If a feature is implemented and available in
some version (even behind a flag) with a clear intent to ship it at some
point, this should be enough for us to follow.
I changed it to "at least two other browser engines ship
On 2013-06-26 12:28 PM, Brian Smith wrote:
I understand that Brendan would like to have more/all web-facing functionality covered by
some kind of guidelines similar to what you propose. I am not against that idea. However,
I don't think the rules you write work very well for the modules I work
On 2013-06-26 12:17 PM, Andrew Overholt wrote:
On 26/06/13 11:48 AM, Ehsan Akhgari wrote:
On 2013-06-26 11:21 AM, Andrew Overholt wrote:
On 24/06/13 05:52 PM, Ehsan Akhgari wrote:
There are two things that I think can use clarification. One is what
we're going to do about "trivial changes"?
Andrew Overholt wrote:
> On 25/06/13 10:11 AM, Brian Smith wrote:
> > In the document, instead of creating a blacklist of web technologies to
> > which the new policy would not apply (CSS, WebGL, WebRTC, etc.), please
> > list the modules to which the policy would apply.
>
> I started building up
On 26/06/13 11:48 AM, Ehsan Akhgari wrote:
On 2013-06-26 11:21 AM, Andrew Overholt wrote:
On 24/06/13 05:52 PM, Ehsan Akhgari wrote:
There are two things that I think can use clarification. One is what
we're going to do about "trivial changes"? Do all web facing features
ned to go through thi
On 25/06/13 12:15 PM, Mounir Lamouri wrote:
Note that at this time, we are specifically focusing on new JS APIs
and not on CSS, WebGL, WebRTC, or other existing features/properties.
I think the "JS APIs" here is unclear. I think saying "Web APIs" would
be more appropriate, assuming this is wh
On 2013-06-26 11:50 AM, Kyle Huey wrote:
On Wed, Jun 26, 2013 at 8:48 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote:
The other question is, what we're going to do about negative
feedback
from the API review phase but where the feedback cannot be
On 2013-06-26 9:09 AM, Robert O'Callahan wrote:
On Google's side, it is harder to find examples because I do not follow
that as closely but requestAutocomplete() is an example of an API that
Mozilla might not look at for quite some time.
If we think these use cases are (or ever will be) relev
On Wed, Jun 26, 2013 at 8:48 AM, Ehsan Akhgari wrote:
>
> The other question is, what we're going to do about negative feedback
>>> from the API review phase but where the feedback cannot be incorporated
>>> because of other concerns?
>>>
>>
>> I was thinking the module owner (or I guess the DOM m
On 2013-06-26 11:21 AM, Andrew Overholt wrote:
On 24/06/13 05:52 PM, Ehsan Akhgari wrote:
There are two things that I think can use clarification. One is what
we're going to do about "trivial changes"? Do all web facing features
ned to go through this process?
I was going to put a blurb abou
On 2013-06-26 11:11 AM, Andrew Overholt wrote:
5. "Once one week has passed [...]
This seems unnecessarily heavy-handed to me.
Agreed so I'll remove it. I'm actually thinking we still have the email
request but only to inform those who are interested in the feature
landing but haven't been fo
On 25/06/13 10:11 AM, Brian Smith wrote:
In the document, instead of creating a blacklist of web technologies to which
the new policy would not apply (CSS, WebGL, WebRTC, etc.), please list the
modules to which the policy would apply.
I started building up a list of modules to which the polic
On 24/06/13 05:52 PM, Ehsan Akhgari wrote:
There are two things that I think can use clarification. One is what
we're going to do about "trivial changes"? Do all web facing features
ned to go through this process?
I was going to put a blurb about "trivial changes" but thought it would
be too
On 24/06/13 01:50 PM, Kyle Huey wrote:
1. "at least one other browser vendor ships -- or publicly states their
intention to ship -- a compatible implementation of this API"
Because Apple and Microsoft generally do not publicly comment on
upcoming features, and Presto is no more, in practice this
On Thu, Jun 27, 2013 at 12:54 AM, Mounir Lamouri wrote:
> On 25/06/13 17:28, Robert O'Callahan wrote:
> > I don't see this. Can you give some examples?
>
> On Mozilla's side, there are a few APIs that we are pushing and do not
> interest other vendors for the moment. Most APIs related to Firefox
On 25/06/13 17:28, Robert O'Callahan wrote:
> On Wed, Jun 26, 2013 at 4:15 AM, Mounir Lamouri wrote:
>
>>> 3. APIs solving use cases which no browser vendor shipping an engine
>>> other Gecko is interested in at that time. In cases such as this,
>>> Mozilla will solicit feedback from as many rele
"during the first 12 months of development of new user-facing
products, APIs that have not yet been embraced by other vendors or
thoroughly discussed by standards bodies may be shipped only as a part
of this product, thus clearly indicating their lack of standardization
and limiting any market shar
On Wed, Jun 26, 2013 at 4:15 AM, Mounir Lamouri wrote:
> > 3. APIs solving use cases which no browser vendor shipping an engine
> > other Gecko is interested in at that time. In cases such as this,
> > Mozilla will solicit feedback from as many relevant parties as
> > possible, begin the standard
On 21/06/13 21:45, Andrew Overholt wrote:
> I'd appreciate your review feedback. Thanks.
Thank you for putting this together.
I am going to quote some parts of the document to give some context to
my comments.
> Note that at this time, we are specifically focusing on new JS APIs
> and not on C
On Tue, Jun 25, 2013 at 11:11 PM, Brian Smith wrote:
> If it is intended that the stuff I work on (networking protocols, security
> protocols, and network security protocols) be covered by the policy, then I
> will reluctantly debate that after the end of the quarter. (I have many
> things to f
I don't really think there is a controversy here network wise - mostly
applicability is a case of "I know it when I see it" and the emphasis here
is on things that are exposed at the webdev level is the right thing.
Sometimes that's markup, sometimes that's header names which can touch on
core prot
Henri Sivonen wrote:
> On Tue, Jun 25, 2013 at 6:08 AM, Brian Smith wrote:
> > At the same time, I doubt such a policy is necessary or helpful for the
> > modules that I am owner/peer of (PSM/Necko), at least at this time.
> > In fact, though I haven't thought about it deeply, most of the recent
>
Robert O'Callahan wrote:
> On Tue, Jun 25, 2013 at 3:08 PM, Brian Smith wrote:
>
> > At the same time, I doubt such a policy is necessary or helpful for the
> > modules that I am owner/peer of (PSM/Necko), at least at this time. In
> > fact, though I haven't thought about it deeply, most of the r
On Tue, Jun 25, 2013 at 10:01:15AM +0300, Henri Sivonen wrote:
> On Tue, Jun 25, 2013 at 6:08 AM, Brian Smith wrote:
> > At the same time, I doubt such a policy is necessary or helpful for the
> > modules
> > that I am owner/peer of (PSM/Necko), at least at this time. In fact, though
> > I
> > h
On Fri, Jun 21, 2013 at 11:45 PM, Andrew Overholt wrote:
> https://wiki.mozilla.org/User:Overholt/APIExposurePolicy
>
> I'd appreciate your review feedback. Thanks.
Thank you for putting this together.
In general, I'd like the point "no prefixing" to be made more
forcefully/clearly.
Further
On Tue, Jun 25, 2013 at 6:08 AM, Brian Smith wrote:
> At the same time, I doubt such a policy is necessary or helpful for the
> modules
> that I am owner/peer of (PSM/Necko), at least at this time. In fact, though I
> haven't thought about it deeply, most of the recent evidence I've observed
> in
On Monday 2013-06-24 20:08 -0700, Brian Smith wrote:
> These clarifications would greatly help me (and probably owners and peers of
> other modules) scope our participation in this discussion. As far as the DOM
> module is concerned, I am mostly part of the peanut gallery so my judgement
> of wh
On Tue, Jun 25, 2013 at 3:08 PM, Brian Smith wrote:
> At the same time, I doubt such a policy is necessary or helpful for the
> modules that I am owner/peer of (PSM/Necko), at least at this time. In
> fact, though I haven't thought about it deeply, most of the recent evidence
> I've observed indi
Andrew Overholt wrote:
> Back in November, Henri Sivonen started a thread here entitled
> "Proposal: Not shipping prefixed APIs on the release channel" [1]. The
> policy of not shipping moz-prefixed APIs in releases was accepted AFAICT.
>
> I've incorporated that policy into a broader one regardi
There are two things that I think can use clarification. One is what
we're going to do about "trivial changes"? Do all web facing features
ned to go through this process?
The other question is, what we're going to do about negative feedback
from the API review phase but where the feedback ca
On 2013-06-24 1:50 PM, Kyle Huey wrote:
1. "at least one other browser vendor ships -- or publicly states their
intention to ship -- a compatible implementation of this API"
Because Apple and Microsoft generally do not publicly comment on upcoming
features, and Presto is no more, in practice thi
On Fri, Jun 21, 2013 at 1:45 PM, Andrew Overholt wrote:
> Back in November, Henri Sivonen started a thread here entitled "Proposal:
> Not shipping prefixed APIs on the release channel" [1]. The policy of not
> shipping moz-prefixed APIs in releases was accepted AFAICT.
>
> I've incorporated that
On 21/06/13 05:56 PM, Adam Roach wrote:
On 6/21/13 15:45, Andrew Overholt wrote:
I'd appreciate your review feedback. Thanks.
I'm having a hard time rectifying these two passages, which seem to be
in direct contradiction:
1. "Note that at this time, we are specifically focusing on /new/ JS
On 21/06/13 06:05 PM, Benoit Jacob wrote:
Just to say, WebGL won't have to be an exception after all --- at least
not newer WebGL extensions.
Ah, thanks for letting me know.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.m
On Fri 21 Jun 2013 06:44:08 PM EDT, Robert O'Callahan wrote:
I think "APIs which only Mozilla is interested in at that time" needs
clarification that this refers to APIs that solve use cases that only
Mozilla is interested in. If other vendors are interested in those
use-cases, but don't like our
I think "APIs which only Mozilla is interested in at that time" needs
clarification that this refers to APIs that solve use cases that only
Mozilla is interested in. If other vendors are interested in those
use-cases, but don't like our API proposal, we can't just brush that off.
Rob
--
Jtehsauts
Note that things started changing in the WebGL world since the last time
that this was discussed.
With the Blink fork, the Chromium community started their switch from
prefixes to behind-a-flag for new WebGL extensions. They didn't change
already-implemented extensions (presumably to avoid breakin
On 6/21/13 15:45, Andrew Overholt wrote:
I'd appreciate your review feedback. Thanks.
I'm having a hard time rectifying these two passages, which seem to be
in direct contradiction:
1. "Note that at this time, we are specifically focusing on /new/ JS
APIs and not on CSS, WebGL, WebRTC,
Back in November, Henri Sivonen started a thread here entitled
"Proposal: Not shipping prefixed APIs on the release channel" [1]. The
policy of not shipping moz-prefixed APIs in releases was accepted AFAICT.
I've incorporated that policy into a broader one regarding web API
exposure. I'd lik
58 matches
Mail list logo
