Re: Intent to implement: nsIDOMMozIccManager.getCardLockRetryCount
Hi Thomas,
MozICCManager is an API available only for built-in applications on
Firefox OS so it is fine to change it as much as you want.
--
Mounir
On 25/06/13 17:11, Thomas Zimmermann wrote:
> Hi,
>
> I intent to implement an extension to nsIDOMMozICCManager.
>
> When unlocking a SIM card, there is a maximum number of remaining tries.
> The new interface 'getCardLockRetryCount' will allow for reading the
> number of remaining tries for a specific lock. During the unlock
> process, an app can display this information to the user, probably in
> conjunction with a descriptive message (e.g, 'You have 3 tries left.').
>
> interface nsIDOMMozIccManager {
> ...
> nsIDOMDOMRequest getCardLockRetryCount(in DOMString lockType);
> ...
> };
>
> The parameter 'lockType' is a string that names the lock. The result is
> a DOM request. On success, it returns the number of retries in its
> result property; on error it returns a error name. An error happens if
> the given lock type is not known or not supported by the implementation.
>
> There is more detailed documentation in bug 875710, comments 17 and 18 [1].
>
> Any feedback and suggestions are welcome.
>
> Best regards
> Thomas
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=875710#c17
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 relevant parties as >>> possible, begin the standardization process with a relevant standards >>> body, and create a test suite as part of the standards process. An >>> example of this is the Push Notifications API. >> >> I am not a big fan of that exception. Given how fast paced the Web is >> nowadays, we could easily put a lot of APIs in that category. > > 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 OS. 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. On Apple and Microsoft side, they do not anyway express intents before shipping but Apple has a history on Webkit iOS for pushing APIs that sometimes ended up in specs and sometimes just stayed as a Apple-only API. >> Actually, >> if we ask other vendors what they think about most Firefox OS APIs, we >> will very likely get no answer. Does that mean that those APIs are good >> to go? > > If "no answer" means "we don't care about your use cases", then we can't > let that block our progress, because there are always going to be use-cases > we need to solve that no other vendor is currently interested in. I agree that getting blocked because other vendors don't care about our use cases is not a good situation. However, it is easy to push bad APIs because no one had time to look into it and then, when they do, having two competing API which ends up in a mess (IDB vs WebSQL for example). My point is not that we will do that on purpose but we are opening a door to situations like these. Cheers, -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 OS. > Right. 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) 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 are something we wouldn't feel bad about implementing, and complain if they are. > > On Apple and Microsoft side, they do not anyway express intents before > shipping but Apple has a history on Webkit iOS for pushing APIs that > sometimes ended up in specs and sometimes just stayed as a Apple-only API. > I know. That's bad behavior on their part. However, I think Apple and Microsoft are mostly followers currently. > If "no answer" means "we don't care about your use cases", then we can't > > let that block our progress, because there are always going to be > use-cases > > we need to solve that no other vendor is currently interested in. > > I agree that getting blocked because other vendors don't care about our > use cases is not a good situation. However, it is easy to push bad APIs > because no one had time to look into it and then, when they do, having > two competing API which ends up in a mess (IDB vs WebSQL for example). > My point is not that we will do that on purpose but we are opening a > door to situations like these. > I think that door has to be opened. AFAIK Apple never really solicited feedback on WebSQL before shipping. Also, there was no attempt to create a proper spec. (A proper spec would have included a spec for SQLite, so if they had done that, maybe we would have adopted it after all!) So I don't think we would repeat the WebSQL error under our proposed policy. So I see your point, but I think it's fair to expect other vendors to provide feedback on our API proposals if they care about the use-cases, and for us to do the same for them. The available bandwidth and level of investment is higher than it used to be. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 will boil down to a minimum condition of the Blink developers stating their intention to ship an API (in Chrome, presumably). That feels too restrictive to me. Blink's policy talks about "positive signals" from other vendors which is much more vague. I worry that the proposed language is too rigid and will either restrict us from innovating or worse, be ignored. What if we clarified earlier in the policy that things hidden behind flags are exempt from these requirements, like Ehsan pointed out Blink does? 4. "Disputes between the API review team and the API developers will be decided by the module owner for the API's area." I'm not sure that there is even a module owner here to decide things. How do you feel about Ehsan's suggestion of using the DOM module owner as an arbiter? 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 following the bug closely. What do you think? What about you, Ehsan? Thanks for the feedback! Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 hard to define. Would you be okay with it being in there with something like "definition of triviality is left up to the module owner"? 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 module owner in certain cases) would make the call. But maybe I'm misunderstanding what sort of feedback you're thinking of; can you give an example? Thanks, Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 policy would apply but it grew quickly and there are a lot of modules in Core. How do you feel about refining the definition of "web-exposed feature" and then saying it applies to all modules but the module owner has veto power for applicability? Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 following the bug closely. What do you think? What about you, Ehsan? Hmm, assuming that we're not blocking people checking in their code to m-c hidden behind a flag, I think it would make sense to reform the intent to implement emails as mostly informational, while giving the people to object if they have a good reason why implementing the feature is a bad idea, but we should still have some way to come to a conclusion for intent to ship emails. I think it would make sense to take a week of silence as consent, to prevent people from having to wait for an extended period of time looking for some reply to their email. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 about "trivial changes" but thought it would be too hard to define. Would you be okay with it being in there with something like "definition of triviality is left up to the module owner"? Do we really need to precisely define it? I mean, at some point we should rely on people to use their best judgement. Of course, needless to say, the module owner will still have the power to act at the final arbiter on these matters. 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 module owner in certain cases) would make the call. But maybe I'm misunderstanding what sort of feedback you're thinking of; can you give an example? Certainly. In our efforts to support Web Audio, we've considered implementing some parts of the API which are not exactly webby after extensive discussions in the working group in the interest of having an interoperable implementation with other engines at some point. We've done so as a compromise. I'm certain that such an API, if it went through the proposed API review process, would get a negative feedback on the API design itself. Assuming that the DOM module owner upholds the opinion of the API review team, it would mean an impasse at the implementation since the feedback of the API review team would not necessarily affect the decision of the Audio Working Group. In this hypothetical scenario, following the process would probably mean that we would be unsable to ever ship Web Audio support. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 module owner in >> certain cases) would make the call. But maybe I'm misunderstanding what >> sort of feedback you're thinking of; can you give an example? >> > > Certainly. In our efforts to support Web Audio, we've considered > implementing some parts of the API which are not exactly webby after > extensive discussions in the working group in the interest of having an > interoperable implementation with other engines at some point. We've done > so as a compromise. I'm certain that such an API, if it went through the > proposed API review process, would get a negative feedback on the API > design itself. Assuming that the DOM module owner upholds the opinion of > the API review team, it would mean an impasse at the implementation since > the feedback of the API review team would not necessarily affect the > decision of the Audio Working Group. In this hypothetical scenario, > following the process would probably mean that we would be unsable to ever > ship Web Audio support. > Any API review that doesn't take into account the need for interoperable implementations and the existence of legacy content is a waste of time. Most of the web would fail an API review then ... - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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) 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 are something we wouldn't feel bad about implementing, and complain if they are. I don't think that in practice we can expect other vendors to give us feedback on all proposed APIs, or that we give them feedback on their proposed APIs. 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), and has also made the decision to ship requestAutocomplete hoping that Hixie will add it to the spec before it hits the Chrome release channel. In the case of Web MIDI at least they have asked us to give feedback on a few occasions, but we've been unable to do so because of not having enough resources. But it looks like they're also interested in making progress on the features that are only interesting to them while making an effort to solicit feedback from other engine vendors. If "no answer" means "we don't care about your use cases", then we can't let that block our progress, because there are always going to be use-cases we need to solve that no other vendor is currently interested in. I agree that getting blocked because other vendors don't care about our use cases is not a good situation. However, it is easy to push bad APIs because no one had time to look into it and then, when they do, having two competing API which ends up in a mess (IDB vs WebSQL for example). My point is not that we will do that on purpose but we are opening a door to situations like these. I think that door has to be opened. AFAIK Apple never really solicited feedback on WebSQL before shipping. Also, there was no attempt to create a proper spec. (A proper spec would have included a spec for SQLite, so if they had done that, maybe we would have adopted it after all!) So I don't think we would repeat the WebSQL error under our proposed policy. So I see your point, but I think it's fair to expect other vendors to provide feedback on our API proposals if they care about the use-cases, and for us to do the same for them. The available bandwidth and level of investment is higher than it used to be. So, are you proposing that we should give feedback on all APIs even if they're not interesting to us? I'd be fine with that, but I don't think we can assume that it will be reciprocated. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 incorporated because of other concerns? I was thinking the module owner (or I guess the DOM module owner in certain cases) would make the call. But maybe I'm misunderstanding what sort of feedback you're thinking of; can you give an example? Certainly. In our efforts to support Web Audio, we've considered implementing some parts of the API which are not exactly webby after extensive discussions in the working group in the interest of having an interoperable implementation with other engines at some point. We've done so as a compromise. I'm certain that such an API, if it went through the proposed API review process, would get a negative feedback on the API design itself. Assuming that the DOM module owner upholds the opinion of the API review team, it would mean an impasse at the implementation since the feedback of the API review team would not necessarily affect the decision of the Audio Working Group. In this hypothetical scenario, following the process would probably mean that we would be unsable to ever ship Web Audio support. Any API review that doesn't take into account the need for interoperable implementations and the existence of legacy content is a waste of time. Most of the web would fail an API review then ... Absolutely, but different people reviewing the APIs can have different priorities, which is why I raised the question on what exactly needs to be done upon receiving negative feedback from the API review. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 what you meant. I waffled on this but if you think "[Ww]eb APIs" is more clear, I'll go with that. 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 CSS property, it is not clear why this shouldn't go trough this process. My hope was to get something in place for APIs and then build up to other web-exposed "things" like CSS, etc. 1. Is the API standardized or on its way to being so? 2. Declaration of intent 3. API review 4. Implementation 5. Shipping I think 2) should be "Declaration of intent to implement" and we should add an item between 4) and 5) named "Declaration of intent to ship". Those two distinct items are important I believe. Done. Although note that others have expressed concern about the "intent to ship"->"shipping" situation. 2. at least two other browser vendors ship a compatible implementation of this API I will join Henri: "browser vendors" should be "browser engines" and Fixed. "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 (regardless if it's behind a flag or not in their equivalent of beta or release) -- a compatible implementation of this API ". How's that? I don't want to see us basing our decision to ship on another engine's use of their nightly equivalent for experimentation (whether this happens right now or not). Am I worried for no reason? 3. at least one other browser vendor ships -- or publicly states their intention to ship -- a compatible implementation of this API and there is a specification that is no longer at risk of significant changes, on track to become a standard with an relevant standards body, and acceptable to a number of applicable parties Actually, with this point, point 2) sounds barely useful. The only situation when we could have 3) applying but not 2) would be if two engines implement a feature that has no specification. That was the situation I was thinking of :) 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 clear disclaimers about applicability of exposed APIs). An example of this is the FM Radio API for Firefox OS. When I read this, I read "It is okay to have Mozilla ship a phone with proprietary APIs". That means that we are okay with Mozilla creating the situation Apple created on Mobile, a situation that Mozilla has been criticising a lot. Shipping proprietary APIs on a specific device is harming the broader Web if that device happens to be one of the most used device out there... The way you read it obviously not something we want to do. What if we dropped the "ecosystem-"? I can't see how we can allow ourselves to ship hardware-specific APIs that don't work everywhere without an exception like this. Are there situations where we would ship such an API on desktop if there's very little chance of the required hardware existing there? 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 standardization process with a relevant standards body, and create a test suite as part of the standards process. An example of this is the Push Notifications API. I am not a big fan of that exception. That was my attempt to not limit our ability to innovate without other engines. I'm open to alternative phrasings. Declaring Intent API review Implementation Shipping I think some clarifications are needed in those areas. I changed the section headers to: Declaring Intent to Implement API review Implementation Intent to Ship and Shipping How's that? Intent emails should be reviewed by "dev-platform", not a "API review team". In other words, any one should be able to express its opinion and opinions will be listened based on their technical value, not based on affiliation. I added some wording to clarify that the email should do _both_. I was also not assuming affiliation would necessarily define the "API review team". The issue with having "dev-platform" finding a consensus with intent emails is that we might end up in a infinite debate. In that case, we should use the module system and have the mo
Re: Making proposal for API exposure official
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 this process? I was going to put a blurb about "trivial changes" but thought it would be too hard to define. Sorry, I was wrong here. I didn't put it in because I intended the policy to only cover new APIs. I guess we could say "new APIs or major changes to existing APIs" ... Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 a list of modules to which the policy would apply > but it grew quickly and there are a lot of modules in Core. There is an easy way to build this list. When a module owner agrees to change the decision making process for his/her module to incorporate the policy, he/she can add his module to the list himself. > How do you feel about refining the definition of "web-exposed feature" > and then saying it applies to all modules but the module owner has veto > power for applicability? Module owners choose how to make decisions in their modules, though they can be overridden by Brendan. I **highly** recommend that you re-read this: http://www.mozilla.org/hacking/module-ownership.html And, in particular: "We do not have an elaborate set of rules or procedures for how module owners manage their modules. If it works and the community is generally happy, great. If it doesn't, let's fix it and learn." 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 in. For example, I don't think this part makes sense for networking or PKI: "The Mozilla API review team will consist of Mozillians who have experience designing JS APIs and will have at least one representative from the JS team at all times." After the quarter is over, I am willing to spend time working with you to try to define a policy that might work better for modules that aren't DOM/JS-related. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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"? 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 hard to define. Sorry, I was wrong here. I didn't put it in because I intended the policy to only cover new APIs. I guess we could say "new APIs or major changes to existing APIs" ... Well, the policy also mentions enforcement through commit hooks (which I don't like!) so it at least looks to cover all API changes. Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 in. For example, I don't think this part makes sense for networking or PKI: "The Mozilla API review team will consist of Mozillians who have experience designing JS APIs and will have at least one representative from the JS team at all times." After the quarter is over, I am willing to spend time working with you to try to define a policy that might work better for modules that aren't DOM/JS-related. I'm still not sure why it won't work well for the modules that you work on. Can you please clarify, perhaps with an example? Are there parts of your work which involves things that web developers can detect which doesn't fit with what's being proposed here? Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 (regardless if it's behind a flag or not in their equivalent of beta or release) -- a compatible implementation of this API ". How's that? I don't want to see us basing our decision to ship on another engine's use of their nightly equivalent for experimentation (whether this happens right now or not). Am I worried for no reason? If another engine has an implementation behind a flag in a prerelease channel, I don't see why we can't coordinate the possible changes that they're considering with them. I don't think that's going to be a huge concern. 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 clear disclaimers about applicability of exposed APIs). An example of this is the FM Radio API for Firefox OS. When I read this, I read "It is okay to have Mozilla ship a phone with proprietary APIs". That means that we are okay with Mozilla creating the situation Apple created on Mobile, a situation that Mozilla has been criticising a lot. Shipping proprietary APIs on a specific device is harming the broader Web if that device happens to be one of the most used device out there... The way you read it obviously not something we want to do. What if we dropped the "ecosystem-"? I can't see how we can allow ourselves to ship hardware-specific APIs that don't work everywhere without an exception like this. Are there situations where we would ship such an API on desktop if there's very little chance of the required hardware existing there? I think what Mounir is worrying about is the reverse situation where people code against our APIs without knowing that they're not available on other devices. Mounir, do you have the same concern about certified Firefox OS APIs? What about privileged APIs? To answer your question, Andrew, I think it would be a good idea to ship our APIs consistently on all platforms where the required hardware is available. The issue with having "dev-platform" finding a consensus with intent emails is that we might end up in a infinite debate. In that case, we should use the module system and have the module owner(s) of the associated area of code make the decision. If the module owner(s) can't take this decision, we could go upward and ask Brendan to make it. I admit I didn't think much about "dev-platform" coming to a consensus. I guess I'd like major disputes to be handled on a case-by-case basis and not have to define what should be done in the infinite discussion situations. Maybe we should just be more forthcoming as reviewers or module owners about something we wouldn't want to ship and thus save potential implementors' time. We should definitely try to prevent people from spending time implementing something that we are never going to ship. But I think Mounir's point is good here. Experience has shown that getting consensus on dev-platform is, well, not very easy. Therefore I think the escalation path that Mounir is proposing is a good idea. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 product". Hmm, is there any reason why we're not explicitly making this about Firefox OS? Talking about a new product means that for example Firefox for Metro can also do this when it's shipped. So far we've been able to avoid a lot of this problem on our more traditional products, so maybe it's not a great idea to open a wildcard for all future products. If, in the future, another product proves to be as different in its requirements and challenges as Firefox OS is, we can always amend the policy to include that as well. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 the document was written with a focus on Web APIs, applying it more broadly to things like network protocols is (I think) a laudable goal, but might require some tweaks. Gavin On Wed, Jun 26, 2013 at 1:17 PM, Ehsan Akhgari wrote: > 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 in. For example, I don't think >> this part makes sense for networking or PKI: "The Mozilla API review team >> will consist of Mozillians who have experience designing JS APIs and will >> have at least one representative from the JS team at all times." After the >> quarter is over, I am willing to spend time working with you to try to >> define a policy that might work better for modules that aren't >> DOM/JS-related. > > > I'm still not sure why it won't work well for the modules that you work on. > Can you please clarify, perhaps with an example? Are there parts of your > work which involves things that web developers can detect which doesn't fit > with what's being proposed here? > > Cheers, > Ehsan > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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/ship SPDY, for example. I think it's clear the document was written with a focus on Web APIs, applying it more broadly to things like network protocols is (I think) a laudable goal, but might require some tweaks. SPDY is not detectable from web script (correct me if I'm wrong) so it's not covered by this spec. Brian, are you objecting to the things which does fall under the scope of the current proposal? Thanks! Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 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 the document was written with a focus on >> Web APIs, applying it more broadly to things like network protocols is >> (I think) a laudable goal, but might require some tweaks. >> > > SPDY is not detectable from web script (correct me if I'm wrong) so it's > not covered by this spec. Brian, are you objecting to the things which > does fall under the scope of the current proposal? > > Thanks! > Ehsan > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bugzilla Keyword Standardization Proposal
Hi Marc, I think this is good, and leads to more clarity than what we have today. I had to squint a bit to get all the information out of the page below, so it may be useful to be a bit more explicit as to what the things will look like in the document itself. A few examples would help as well. The way I understand it, you're keeping regressionwindow-wanted, steps-wanted and testcase-wanted as the request keywords and setting qawanted, qaurgent and blank as the urgency flag on those requests? I know I would benefit from seeing some of those combinations with a description of what they mean and what kind of response or attention they will get. On 2013-06-25, at 18:13 , Marc Schifer wrote: > > Posted this to dev.planning as well. > > > We in QA have been discussing ways to help improve our workflows and provide > some standardization across the teams in how we use Bugzilla. As part of this > process we have come up with a proposal to make a small change to the > definition of qawanted keyword and the addition of a new keyword qaurgent > > Please read the proposal linked below and give us your feed back. > > https://wiki.mozilla.org/QA/qawanted_proposal > > Marc S. > > ___ > dev-planning mailing list > dev-plann...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-planning > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 coordination in all web facing things. Mozilla should seek partners and consensus, seek to be an honest broker, consider the imprint of our footsteps, and be public in all we do. I'm on board with that idea in the networking space - and if we think that as a statement of principle it is an important thing to document - let's do so! But the underlying spirit of the proposal seems to assume a problem that isn't in evidence beyond the webapi space. I spend my days in roughly equal parts with the IETF, with my team, with our code, and with implementers outside of gecko doing interop (both clients and servers, which is a bit of a different working relationship than webapi faces). I'm fortunate to work with some very cooperative folks both in industry and academia and there is strong awareness of the need to balance innovation against fragmentation. If anything, I think we (as an industry) rock too few boats for the overall health of the web. Therefore I disagree with the relevance of the proposal's bureaucracy to non webapi work. Obviously web idl reviewers, js team members, and blink-coordinated-mailing-lists aren't the primary stake holders in a discussion of congestion control algorithms, tls options, or data-on-syn approaches. If we think red tape beyond a statement of principle is really needed for non webapi spaces, then its probably best to fork the proposal into other module specific documents and let those proceed in parallel. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
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 are something we wouldn't feel bad about >> implementing, and complain if they are. >> > > I don't think that in practice we can expect other vendors to give us > feedback on all proposed APIs, or that we give them feedback on their > proposed APIs. > I agree, which is why the default for the no-feedback situation has to be forward progress, not deadlock. 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), and has also made the decision to ship > requestAutocomplete hoping that Hixie will add it to the spec before it > hits the Chrome release channel. In the case of Web MIDI at least they > have asked us to give feedback on a few occasions, but we've been unable to > do so because of not having enough resources. But it looks like they're > also interested in making progress on the features that are only > interesting to them while making an effort to solicit feedback from other > engine vendors. I think they've done the right thing here for Web MIDI. They've produced a spec, invited feedback, and confirmed that at least we don't have objections. So, are you proposing that we should give feedback on all APIs even if > they're not interesting to us? 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'd be fine with that, but I don't think we can assume that it will be > reciprocated. > That doesn't matter. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Best way to make xpcshell provide consistent stack limits?
For B2G's gaia repository we are currently using xpcshell[1] as our command line JS runner. I was noticing some horrible inconsistencies in terms of blowing the JS stack when we were trying to use the esprima JS parser[2] that varied by the platform and build type. The nutshell is that the #defines at http://dxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#l2687 net us the following JS stack limits. (These are the limits when the JS engine starts throwing "InternalError: too much recursion" and are somewhat separate from actual native stack limits.) linux (32 bit, non-debug): 512 KiB windows (all builds): 900 KiB [3] linux (32 bit, debug): 1 MiB linux (64 bit, non-debug): 1 MiB linux (64-bit, debug): 2 MiB OS X (all): 7 MiB For gaia's purposes, this inconsistency is not great. How should we resolve this? a) Make xpcshell try and pick more consistent values itself b) Make xpcshell take a command line argument and call JS_SetNativeStackQuota plus doing whatever it needs to back that up with an appropriate platform stack (possibly by re-exec()ing). (Similar to node.js supporting --stack_size which defaults to 984 for me right now.) c) Change xpconnect's hard-coded defaults d) Change xpconnect to use jsnativestack.cpp's ability to tell us what the platform stack size actually is and/or nsThread's knowledge of the stack size it was created with. So on linux we'd use whatever 'ulimit -s' is telling us to do, etc. e) Don't use xpcshell for that! Are you crazy?! f) Other Thanks, Andrew 1: Although in the future this might end up just being any xulrunner "-app" capable build. 2: Since the esprima JS parser produces a parse-tree that's supposed to confirm to what SpiderMonkey's Reflect API produces, we do have a work-around, but I expect this stack issue to come up again in the future. 3: The windows limit could be higher by its current rationale; https://bugzilla.mozilla.org/show_bug.cgi?id=582910 increased the windows stack to 2 MiB from 1MiB. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
