Mozilla Developer Resource Kit
Mozilla Developer Resource Kit
This project will create a resource kit suitable for both developers and educators alike, and contain all the code, tools, build environment, documentation, and learning materials necessary to become a productive Mozilla developer and contributor.
See bug 117214.
- David Humphrey
- Chris Tyler
- James Boston
- Mohak Vyas
- Cesar Oliveira
Mozilla is a large and difficult project to get started on because of its scale and scope. A number of issues stand in the way for new contributors:
- tools and documentation is often scattered across the web in wikis, blogs, forums, etc. This situation has improved greatly in recent years, with improvements to MDC. However, MDC is not enough on its own, and suffers from a lack of top-level paths through the enormous amounts of content (i.e., reference vs. learning).
- often one needs more than just a tool or instructions on how to use it--examples, tutorials, etc. are also useful
- many developers, especially those in the east where bandwidth is lacking, struggle to use web-based resources. Having local access to Mozilla's large resources (mxr, mdc, source) would open this world to a new set of developers
- developers coming from proprietary platforms and development environments are used to the concept of resource kits, and find Mozilla's distributed approach to knowledge and resources foreign.
The goal of this project is to create a set of discs that remote users could download or order and begin learning and developing Mozilla easily.
Resource Kit Contents
The resource kit will be contained on one or more discs (
likely onemultiple DVDs). The disc or discs will contain a number of resources:
Complete Linux Development Environment
The kit will include a complete Linux-based Mozilla development environment. This will be done in order to introduce Windows developers to the need for cross platform development and testing, and also to help transition them onto other platforms like Linux and OS X.
The OS chosen would be Fedora Core, and the included software/packages would match, or be compatible with, the Linux Build instructions, the Linux reference platform doc, and the existing Linux Reference VM. We would not use the existing reference VM because our goal is to add convenience software and settings such that Mozilla development is made easier for new developers and so that Windows developers are made to feel comfortable.
This Linux development environment will be available in a number of formats:
- LiveCD, which is also installable
- VM Image. I have contacted VMWare to see if it is possible to redistribute the VMWare Player. Other hosts are also possible, but need to work well so that developers aren't turned-off Linux based on the Windows host software. UPDATE I have filled out the VMware Player Distribution Questionnaire, and am waiting for further information.
Consider using desktop wallpaper from http://www.hongkiat.com/blog/70-nice-and-beautiful-firefox-wallpapers/ or http://www.zuneo.fr/2005/01/wallpapers-firefox.html
Ideally these would be installable via a single setup/wizard/installer as options, or perhaps in the model of the Open CD (i.e., a XUL Runner web based installer, where you choose each package separately).
- Visual C++ 2005 Express Edition - checking with Microsoft to see what choices there are for including or auto-downloading this. UPDATE:
Lots of uncertainty on Microsoft's side (I've spoken to people in the OS Lab + on the VS.NET team). Still trying to find a solution that doesn't involve manual installation.Finally got word from Doug Handler, Technical Product Manager with Microsoft, who says: "The MSFT distribution agreement basically states that no other software besides the MSFT image can be on the disc. This means that if the author / whomever, wants to distribute VS Express and other software on media that 2 discs need to be included." I'm following-up to get this finalized.
- Microsoft Platform SDK (NOTE: When installing the SDK, you must install at least the "Windows Core SDK" (Tools, Build Environment, and Redistributable Components) and the "Web Workshop SDK" (Build Environment)).
- Mozilla Build 1.3
- CVS that works with the source server (http://ftp.gnu.org/non-gnu/cvs/binary/stable/x86-woe/cvs-1-11-22.zip)
- Firebug - more recent version here.
- Extension Developers Extension
- Chrome List - could tie the LXR stuff into the local MXR instance
- Execute JS
- XUL Explorer 0.8
- DOMi - NOTE: AMO URL when it goes up.
- KomodoEdit -
checking with ActiveState to see what's possible here in terms of redistributingShane confirms that we can redistribute. It would be cool to also bundle some custom Mozilla-dev specific extensions, similar to what Shane discusses here. I've emailed for clarification on whether this is possible.UPDATE: Shane confirms that something like this is possible, and suggests the best route is to do "Komodo Edit plus Dev Pack."
Scripts and other Best Practices resources
- Editor config files and addons for common/supported editors
- .mozconfig files for standard development scenarios
As much as possible, provide source code for the Mozilla-based tools included in the kit. This is partly done to make it possible to write learning and other resource material that discusses code explicitly, but also in order to provide an example of the importance of providing open source code.
- Firefox (trunk size = 314M)
- Tagged major release version (probably Firefox 3). This version of the code would be used in almost all examples and document resources
- Trunk version. This would be useful for people with limited bandwidth, because they could cvs update this version instead of having to pull the entire tree
Local Versions of Remote Mozilla Tools
These resources/tools are all web based, and would be hosted in a combined web application hosted locally. Ideally this would mean a Prism or XULRunner app, specialized to host them (cf. http://wiki.oxymoronical.com/Projects:MozDevDocs)
This local web app would have different sections, including:
The local app would include a "Front Page" that allows navigation to the tools, documentation, and other resources. One idea is to include a news feed so that developers could start to get connected to the community and see what's happening in the developer space.
One of the goals of the kit is to provide local access to Mozilla learning, reference, and source code documentation. The local web app should include a sidebar and header suitable for users to quickly navigate and discover what is available. This means quick access to different types of searches (e.g., code index and also documentation), top-down categorization of documentation materials, etc.
Should the top-level organization of the app be content or chrome? Using something like ext's complex layout could be interesting.
Consider using ext.js + jquery to do the category/TOC tree. Could also use this extjs FileTree widget. Also, since glimpse is being used for MXR, perhaps it can also be used to do the indexing of the static documentation.
The local MXR would index only the trees in the kit (see the Source Code section). The look of the HTML pages should be modified somewhat to make it clear that this is a separate resource to what is on the web, and therefore the code indexed is not the same. See the Create Local MXR project for more details.
UPDATE: I've got a working prototype:
Filed bug 435814 to track my work integrating dehydra and mxr.
Web-Based Mozilla Tools
- Using the nserror info at http://silver.uwcs.co.uk/mozilla/misc/nserror_list, create an equivalent version to this to run locally, perhaps running in JS only.
- Ted's Extension Wizard: http://ted.mielczarek.org/code/mozilla/extensionwiz/extensionwiz_source.zip
- XUL Periodic Table: http://www.xulplanet.com/references/xulpt/top.xul (OK to use? Need to confirm). See notes on how to embed xul fragments in an html doc.
Documentation and Learning Materials
In addition to MDC, many other types of documentation would be included in the kit, some of which exist and some which would need to be created. Wherever possible, the documentation in the kit would refer to things in the kit--the kit should be self-contained as much as possible.
- Documentation on using each of the tools included in the kit
- Reference and other Documentation (much from MDC). Where MDC is a wiki meant for distributed collaboration, the documentation in the kit is read-only. Furthermore, where wikis prefer writers to readers, the documentation in the kit needs more top-down organization to link everything together (cf. MSDN). Getting rid of the wiki would mean that the content can be distributed as files vs. needing a web/wiki server. Like the local MXR, the look-and-feel of the pages should be altered so that they don't appear to be MDC, and it's clear that this is something separate. In addition, some docs would need to be changed sho they reference the contents of the kit (i.e., where multiple tools can be used, focus on the one(s) that are included in the kit). See notes on MediaWiki Import and Export. UPDATE: Eric Shepherd has given us a sanitized mysql dump from MDC - 2008-04-28. Instructions for recreating devmowiki are here.
- Learning materials (much from Seneca courses)
- API Reference - Neil Deakin has agreed to help by providing his 1.9 XPCOM Reference he created for XULPlanet (just over 1MB). UPDATE: Neil has sent us his perl scripts for generating this content.
- Interviews, articles, substantial blog posts, etc. from Mozilla Developers
- Bibliography/Lists of non-free books of interest to Mozilla Developers
- Glossary of Terms
The user will get copies of the latest stable releases of popular Mozilla software. This is not strictly necessary for development, but helps give a sense of what's possible with the Mozilla platform. NOTE: these could be bundled on a supplementary disc:
- How to deal with localization?
- Can we allow the user to modify VS such that it knows about the symbol/source server when debugging?
- Is it wise to give source that can't be built? I'm thiking of Miro, OpenKomodo, etc. for which you need a different toolchain than Firefox (version wise). My idea in including them is that you can refer to them. Maybe this makes it more difficult rather than less so.
- What's the best way to use MDC and other Mozilla documentation in this such that future releases don't need a lot of manual work to pull in new material?
- Should source code for popular extensions be included and indexed? This might be nice in terms of providing learning/teaching materials for extension developers.
- Need to clear copyright and licensing on all materials to be used.
- Should there be more than one? For example, Academic version, Developer version? I lean toward 'no', but perhaps some types of content could be put on a separate disc?
- There should also be an Enterprise Deployment version (NOTE: trying to get a student to do this with mkaply)
- Is it worth mining the newsgroups for info?
- What about Mac OS X?
- Can I leverage the Mozilla update system for extensions to push content updates?
Should the various and scattered "How to make an extension" online resources be part of the MDRK? (consider it is probably an interesting first step in Mozilla code for many a beginner)Yes, they will be.
Example Resource Kits
- http://developer.apple.com/samplecode/AppleApplications/index.html (example of how Apple works with categories vs. trees).
- Create Linux build/dev environment, perhaps as a project in the fall.
- Finalize agreement with Microsoft to redistribute VS.NET Express
- Collect all software and other binary materials to go on the discs
- Write "one pagers" on all the tools included with the kit
- Build tree hierarchy for MDC content using a file-system dir structure (likely more than one root, e.g., Reference, Books, Tutorials, etc.)
- Write tool to parse a "transformation" script, which would take page titles and copy them to category dirs, delete them, etc. The basic idea is to avoid touching the files from MDC manually.
- Do a wget of the MDC mirror on liberia, which does *not* pull in any outside materials.
- Create a "transformation" script to automate the process of classifying and cleaning the MDC content generated by the wget, such that it is never done manually:
- Find and kill all red links in the MDC content (i.e., transform them into plain text).
- Find and kill all place-holder docs which have little or no valuable content.
- Delete any docs that are not in scope for the kit (e.g., docs that refer to things not specifically about Mozilla development)
- Explore packaging options for the web-based content via Prism/XULRunner. This also includes an httpd/perl-cgi solution for Windows that doesn't suck--perhaps an embedded extension solution?