WebAPI/PlannedWork: Difference between revisions

Jump to navigation Jump to search

WebAPI/PlannedWork (view source)

Revision as of 21:11, 28 April 2013

182 bytes added ,  28 April 2013
try to organize a bit this list
No edit summary
(try to organize a bit this list)
Line 2: Line 2:
<div style="font-size:x-small">This is a backlog of ideas for potential future work.  Nothing is committed until it lands in a release :) .</div></div>
<div style="font-size:x-small">This is a backlog of ideas for potential future work.  Nothing is committed until it lands in a release :) .</div></div>


* DOM Futures
== New Firefox OS APIs ==
** http://dom.spec.whatwg.org/#futures
 
* Sync API (sicking)
** ex. keep GMail synchronized
* [https://wiki.mozilla.org/WebAPI/Inter_App_Communication Inter App Communication]
* [https://wiki.mozilla.org/WebAPI/Inter_App_Communication Inter App Communication]
* storage.js
* [https://wiki.mozilla.org/WebAPI/DataStore Data Store]
** as implementation solidifies, will want input from Gaia, others
 
** related:  https://wiki.mozilla.org/WebAPI/Storage2013
== Fix/maintain current Firefox OS APIs ==
* appcache
 
** Jonas' proposal:  http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0977.html
** Alex Russell's work:  https://github.com/slightlyoff/NavigationController/
* audio manager API (baku)
* Change <iframe mozbrowser> to <webview> (or whatever).
** Right now the mozbrowser API doesn't get loaded until some time after the iframe is inserted into the DOM.  This makes things difficult for clients who would like to be able to count on e.g. always being able to call setVisible().
** When we make this change, we should look into converting mozbrowser into C++.  Loading it currently has relatively high overhead, and we've put in a bunch of hacks to work around it.
** If we do this, we should coordinate this HTML parser hack somehow and probably not expose it (and not reserve "webview" as a name for normal content).
* Build a Web API dashboard similar to chromestatus.com, see if we can integrate it with the devtools UI, and what other cool things we can do with it. (ehsan)
* Fix browser API (jlebar)
* Fix browser API (jlebar)
** don't use iframe element
** don't use iframe element
Line 26: Line 20:
** doesn't behave sanely with multiple windows attempting to access it
** doesn't behave sanely with multiple windows attempting to access it
** will likely require major changes
** will likely require major changes
* Sync API (sicking)
* AudioManager (baku)
** ex. keep GMail synchronized
** anything else to do?
* Bluetooth work may have fallout work (Team Ben)
* Contacts API in desktop, related permissions situation
** We are planning to deprecate the current Contacts API so we should make sure that we keep that into consideration
 
== API standardizations ==
 
* Change <iframe mozbrowser> to <webview> (or whatever).
** Right now the mozbrowser API doesn't get loaded until some time after the iframe is inserted into the DOM.  This makes things difficult for clients who would like to be able to count on e.g. always being able to call setVisible().
** When we make this change, we should look into converting mozbrowser into C++.  Loading it currently has relatively high overhead, and we've put in a bunch of hacks to work around it.
** If we do this, we should coordinate this HTML parser hack somehow and probably not expose it (and not reserve "webview" as a name for normal content).
 
== General DOM stuff ==
 
* [http://dom.spec.whatwg.org/#futures DOM Futures]
* [http://github.com/mounirlamouri/storage.js storage.js]
** related to https://wiki.mozilla.org/WebAPI/Storage2013
* [http://url.spec.whatwg.org/#api URL API] (sicking)
* [http://url.spec.whatwg.org/#api URL API] (sicking)
* clean up rich text editing
* Speech API
** isn't smaug working on that?
* Improve appcache
** Mozilla's proposal:  http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0977.html
** Google's NavigationController:  https://github.com/slightlyoff/NavigationController/
* Storage
* Storage
** Sandboxed Filesystem
** Sandboxed Filesystem
** Quota API
** Quota API
** Data-moving (temp -> perm)
** Data-moving (temp -> perm)
** move appcache and localStorage to centralized quota manager
** move appcache, cookies and localStorage to centralized quota manager
*** also cookies
** speak with necko team about disk cache work
** speak with necko team about disk cache work
* support shared workers and background workers explicitly for things like social API (?) (dougt)
* support shared workers and background workers explicitly for things like social API (?) (dougt)
** support web pages and apps doing something in the background
** support web pages and apps doing something in the background
* do we still want to change the security model of workers as sicking at some point suggested?
 
** loading has same-origin limitation
== General Gecko stuff ==
* worker-ification of existing APIs
 
** make this easier
* Expose audio API to Firefox Desktop Internal code
* integrate better with profiling tools
* integrate better with profiling tools
** work with SPS profiler people
** work with SPS profiler people
** IDB performance
** IDB performance
** for both B2G and Firefox
** for both B2G and Firefox
* Bluetooth work may have fallout work (Team Ben)
* Expose audio API to Firefox Desktop Internal code
* clean up rich text editing
 
* speech API
== Misc ==
* Contacts API in desktop, related permissions situation
 
* Build a Web API dashboard similar to chromestatus.com, see if we can integrate it with the devtools UI, and what other cool things we can do with it. (ehsan)
* tests
* tests
* resolving intermittent test failures
* resolving intermittent test failures
* High-level goal: obsolete the app store model
* worker-ification of existing APIs
** Reasoning: if we avoid that kind of dependency, the web really is the platform
** make this easier
** Todo: figure out how to make that happen
 
** remove divide between apps and web, especially WRT security
== Untriaged / open questions ==
 
* do we still want to change the security model of workers as sicking at some point suggested?
** loading has same-origin limitation
Mounir.lamouri
Confirmed users
368

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/650141"

Navigation menu