Changes

Jump to: navigation, search

Roadmap Scratchpad

4,941 bytes added, 08:56, 1 November 2005
no edit summary
So, this is the "platform" roadmap. The other document, the "product" roadmap, builds on this one to detail the plans for Firefox 2 and Firefox 3. Products such as Thunderbird, and projects such as Sunbird, will likely adapt their roadmaps to match the product/platform pair centered on Firefox and Gecko.
The work described in this document will be performed -- in several cases it is already <i>being</i> performed -- on the trunk of Mozilla CVS, with the 1.8 branch preserved largely intact. Some of the features listed below may be pulled forward into that 1.8 branch if needed for product releases off that branch, but you shouldn't count on it. We will preserve all API (declared-frozen or not) compatibility on the 1.8 branch, so only selected additional APIs are thinkable. Readers of this document will notice a conspicuous absence of bug lists, detailed schedules, or decomposition of development work into individual tasks. While this roadmap is intended to provide a statement of direction for the platform in Gecko 1.9, responsibility for detailed planning of such areas of development is necessarily devolved to the groups doing -- or, in the case of some larger tasks, leading -- the design, development, and testing of specific capabilities. In due, and short, time, this document will link to more detailed "sub-roadmaps" for such work; this distribution of ownership will better reflect the structure of our development organization, and should facilitate improved maintenance of the collected roadmap information over the course of Gecko 1.9 The owner of record for this document is Mike Shaver (shaver@mozilla.org), and all errors or omissions within it are first and foremost his responsibility. Brendan Eich (brendan@mozilla.org) continues to drive the vision and architecture of the platform in the large, and his influence on the platform roadmap is both significant and indispensible. In the case of a tie, disputes will be settled by single combat.
= Major Areas Of Development =
The layout changes -- see also the "XUL' and XBL2" section of this roadmap -- center around David Baron's "reflow branch", the aim of which is to eliminate reflow commands and types, and significantly reduce the complexity of the Gecko layout model. This is the first change to global layout architecture in several years, and it is hoped that it will address many problems related to incremental reflow. In addition, it should simplify some problems that are not practically soluble with the current architecture, such as support for inline-table.
=== * cairo substrate ====== * SVG 1.1 ====== * Canvas ====== * XUL2D ====== * "Reflow branch" ===
== JavaScript 2 ==
Improvements to the XUL box model, based on the specification work started by Hixie and Hyatt, should provide a more consistent and flexible layout model for XUL developers, and help to rationalize XUL's interactions with other content types. This box-model work has been proposed for standardization via the W3C CSS working group. Much of the gain in any "shining XUL2 jewel" plan would likely be delivered by these box-model fixed, improvements, and cross-content rationalization, rendering the former not only a non-goal but also a non-issue.
 
We will also see the landing of Neil Deakin's highly-anticipated template builder refactoring, which will allow us to support the use of templates to generate content from data sources such as sqlite (mozStorage), XML documents and JavaScript generators, in addition to the current RDF datasource support. While this work will apply to all content languages, we expect that it will be used first, and perhaps best, by XUL developers who have been suffering with the limitations of the current template model.
 
* XBL2
* XUL box model rationalization
* Template builder
== Web app deployment and capability improvements ==
Another limitation often decried by developers of rich Web applications is the lack of a reasonable offline execution model. Mechanisms to remedy this lack include: facility to pin sets of pages for offline use; a mechanism for detecting that the application is running offline; and events to signal that the user is going offline or returning to online operation. Taken together with the aforementioned client-local storage system, these mechanisms would combine to enable a number of improved and important web experiences.
=== * Offline operation ====== * Client-local storage ===
== Embedding and application deployment ==
Instead, we will make our own applications use the same interfaces that we recommend for embedders, in both C++ Gecko interaction and the XUL widgetry that is composed above it. For launching applications atop our platform, we will improve and promote XULRunner, and use it to launch Firefox and our other applications. Over time, we seek to drive the number of "embedding bugs", as distinct from "bugs that break our apps", to near-zero by improving alignment and overlap between those domains.
=== To further improve the coverage and reliability of our offerings to these developers, the embedding interfaces appropriate to each platform will be built and distributed as part of each XULRunner, and therefore Firefox, package. This embedding interfaces include an ActiveX control on Windows, gtkmozembed on GTK-based platforms, and the embedding widget currently provided by Camino on Macintosh systems. * API convergence* XULRunner ====== * Embedding APIs, widgets, and frameworks  ==Miscellaneous platform improvements == In addition to the above new and enhanced capabilities, there are several important areas of improvement which resist even the preceding attempt at categorization. They are no less important for that mismatch. The security model for web content relies on careful management of trust labels, the mixing of which has long been known to security researchers as a source of significant danger. Also, Gecko's support for content with elevated privileges, derived from the Java privilege model from the time of Netscape 2, does not sufficiently distinguish between web applications which can be trusted to not spoof application UI or attempt to "drive by" extension installation, and those which seek to run arbitrary code on the host machine or perform unrestricted operations on the local filesystem. Building on successful research from the programming-language security community; lessons from Java and .NET; and our own person-centuries of experience building and reinforcing web security models, we seek to provide a richer and more reliable model of trusted execution, and especially "partially-trusted" execution. Extensions have proven to be a very valuable mechanism for extending and improving Firefox and other "toolkit" applications. More sophisticated dependency handling, streaming or stubbed install, and cross-application extension management will be combined with support for additional types of extensions such as language packs and search tools. Combined with application-level improvements in overlay-point freezing or other such advancements, these should provide significant benefits to developers of extensions to Gecko 1.9-hosted applications.
== Elements The development of rich web applications requires sophisticated debugging and analysis tools, and this extends to applications built on web-like platforms like Gecko. Mozilla has provided tools such as the Venkman JavaScript debugger and the DOM Inspector to assist developers of such applications, and we will continue to make improvements in Gecko to support corresponding improvements in these and similar tools. While we do not anticipate the development of a fully integrated development environment, and do not necessarily feel that resist categorization ==such IDEs are of value to the majority of web-application developers, we will undertake to support the development of such tools through improved introspection and debugging interfaces. The [[#JavaScript_2"|JavaScript 2]] work includes such debugging improvements, and we will roll the layout-interface elements of the DOM Inspector into Gecko proper to facilitate the development and distribution of such introspection tools. Projects such as Eclipse may also be served by the inclusion of additional language bindings, as we plan to do for [[#Python_for_XUL|Python]].
=== * Security model improvements ====== * Extension manager ===* Tooling support
Shaver
Confirm
455
edits
Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/13179"

Navigation menu