WebExtensions/NewAPIs: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
Line 5: Line 5:
We want to allow new API's, but we can't just allow everything. Here's a criteria for how we could look at new API's.
We want to allow new API's, but we can't just allow everything. Here's a criteria for how we could look at new API's.


This document is currently a draft, feedback is wanted. This is based on a conversation at the WebExtensions work week in Berlin in March 2016. There will probably be some updates after that.3
This document is currently a draft, feedback is wanted.  


= Rationale =
= Submitting an API? =
 
If you have an API you'd like to see implemented, then:
 
Currently:
* file a new bug in Bugzilla under [https://bugzilla.mozilla.org/enter_bug.cgi?product=Toolkit&component=WebExtensions Toolkit > Web Extensions]
* if its a reasonably obvious we'll add [design-decision-approved] into the white board
* if not we'll add [design-decision-needed] to indicate that we should probably think about, maybe in the [[WebExtensions/AdvisoryGroup]]
 
If you'd like to just chat to someone about an API, then you can contact the [https://mail.mozilla.org/listinfo/dev-addons dev-addons] mailing list.
 
Future:
* we are looking at landing something like [[WebExtensions/Experiments]]
* when that happens, we'll get a process of suggesting and submitting an API through that
 
= Details =


New APIs will need to be built and people will request them. Sadly not all of them should be added, we need a criteria for deciding what should and shouldn't be added so we can be '''consistent and transparent''' with our choices.
New APIs will need to be built and people will request them. Sadly not all of them should be added, we need a criteria for deciding what should and shouldn't be added so we can be '''consistent and transparent''' with our choices.


= Criteria =
== Criteria ==


When we evaluate a new API we should look at, in no particular order:
When we evaluate a new API we should look at, in no particular order:
Line 25: Line 40:
* Performance: does the API create an unacceptable performance penalty for the add-on user?
* Performance: does the API create an unacceptable performance penalty for the add-on user?


== Examples ==
=== Examples ===


At the Berlin work week, we ran through a few scenarios and talked about them to see how this process would work. These are just examples as we learnt the process.
At the Berlin work week, we ran through a few scenarios and talked about them to see how this process would work. These are just examples as we learnt the process.


=== Enable "TCP and UDP Socket API" ===
==== Enable "TCP and UDP Socket API" ====
{{ Bugzilla|1247628}}
{{ Bugzilla|1247628}}


Line 39: Line 54:
Verdict? Yes, but questions about the security concerns.
Verdict? Yes, but questions about the security concerns.


=== Implement WebSQL ===
==== Implement WebSQL ====
{{ Bugzilla|1247329}}
{{ Bugzilla|1247329}}


Line 49: Line 64:
Verdict? No.
Verdict? No.


=== Implement an API for location bar ===
==== Implement an API for location bar ====
{{ Bugzilla|1215060}}
{{ Bugzilla|1215060}}


Line 57: Line 72:


Verdict? Yes
Verdict? Yes
= Submitting an API? =
If you have an API you'd like to see implemented, then:
Currently:
* fill out the [http://bit.ly/webextensions-apis WebExtensions API survey]
* file a new bug in Toolkit > Web Extensions
* we'll add [design-decision-needed] into the white board and it can come before the team
Future:
* we are looking at landing something like [[WebExtensions/Experiments]]
* when that happens, we'd get a process of suggesting and submitting an API through that
Confirmed users
1,158

edits

Navigation menu