Status: Work in Progress
Firebug Extension System Specific Goals
- Testing
- Firebug
- Firebug extensions
- Firebug with Firebug extensions
- Firebug with third party extensions
- Simplicity: For developers and end users
- Generality: To support Firebug, Firebug Extensions, YSlow and other extensions
- Sample extension creation wizard
- Documentation
- Firebug Internals
- Firebug extension points
- Sample extension code
- Extension FAQ
- Architecture: Modular backend REST API and frontend AJAX interface
Focus
- Wizard for new extensions
- co-testing & co-marketing for existing extensions
- When building website focus on test creation
- Use wiki on FWG to collect extension information for now
- when building extensions
- a lot of time spent with domplate and integrating with firebug
- firebug development is moving fast, can be a challenge to keep extensions updated
- Move from Monkey patching in extensions to using firebug extension points
- Utilize existing tools
Questions
- Programming Language? PHP/Java + XML/JSON + HTML/CSS/JavaScript + DB Layer
- Priorities?
- For Project
- Overall Firebug Development
- Hosting? Initially firebug.christophdorn.com eventually developer.getfirebug.com
- Licensing? New BSD
- Code Repository? GitHib
- Project Team? Christoph (lead), Stoyan
- Timeline?
- Proposed name: Developer Companion
- A generic tool with modular features
- A meta data system for software projects accessible via REST API
- A plugin execution system for any and all project and development related tasks (tests, builds, docs, source analysis)
- A Web 2.0 interface that can be used as a "developer" site
- Integration with all popular development tools (via plugins)
Tasks
- Honza
- Prepare some documentation of all the current extension-points
- Christoph
- Get project environment setup
Initial Idea
http://groups.google.com/group/firebug-working-group/browse_thread/thread/b3ebfe8ceb4025ce
I was wondering if you have a best of breed sample firebug 1.4 extension that shows all popular integration points with Firebug?
I think such an extension with clearly documented source code will tremendously help people learning how to extend firebug. The source code for the extension could reside on GitHub allowing anyone to fork the code and experiment with their own additions. I can write a one-click publisher that can generate complete installable and upgradable Firebug extensions from github. The extensions could be listed on the
Firebug site.
Bringing a standard to how extensions are written, hosted and downloaded will help in furthering the extension ecosystem. It would also allow you to more easily absorb certain extension features into the Firebug core.
I can get the whole thing started. What I am looking for is a commitment from the Firebug working group to regularly add sample extension code as they develop extension features into the Firebug core. I will not have the time to maintain the sample extension code long-term, but I can surely set the system up and implement it in such a way that it becomes an asset to Firebug development.
I just want to clarify that my motivation is to build an extension ecosystem, not just a tool to generate one initial extension for developers to get started. With the term ecosystem I am referring to a set of tools, standards, documentation and services that can be leveraged by developers to create skeleton extensions with example code, support the developer in writing their extension and generate installable XPI's for distribution.
The goals for me would be:
- Develop a way to define and document extension points possibly by using annotations in the code and supplementing these with detailed info files in textile format that also reside in SVN. These can then be used to auto-generate documentation for extension developers and will ensure the information is up-to-date as it will be trivial to maintain.
- Provide fireunit tests covering all use cases of all extension points along with inline documentation that can also be re-formatted to be integrated into the extension documentation.
- Provide a unified testing service where firebug extensions can be tested against different firebug code branches provided that the extensions also use fireunit or other tests. This service can be used to proactively notify extension developers by email when certain firebug changes will affect their extensions.
- Provide a subset view into firebug issues concerning extension functionality allowing extension developers to view and file requests for new integration points.
- Provide a service similar to a "pastebin" for extension code allowing FWG members and other developers to provide functional sample code as answers to extension questions on the google group. Once unit tests are added these examples can also be added to the standard firebug tests.
The idea is to build an environment that fosters high-quality Firebug extensions by making integrated development and testing easily available to all authors. Ideally the whole system will be generic so it can be easily used with other Firefox, Thunderbird, etc. extensions.
I think it should be a layered approach. Extension code will reside under version control. Then there will be an application (ideally for me in PHP using ZendFramework) providing all underlying extension ecosystem functionality via a REST API. There can then be several UI's. One for firebug.com pulling out relevant info for end-users. Another one for developer.firebug.com which could provide the full set of extension tools. We can also provide interfaces for integration into IDE's etc...
It would be great to incorporate DomlateRunner into the extension tools so you can develop templates later to be used in extensions in a more practical and easier to develop environment. It would be awesome if you could log a complex object, select it in firebug, launch domplate runner, write a custom renderer for the object, publish an extension with one click and then be able to render the object using your own renderer in the console.
I don't have a problem with having all original source code and docs reside in the current SVN repo. I suggested GitHub because it allows forking of projects while keeping a relationship with the original project to enable easy code exchange and tracking of updates over time. We can support both SVN and GIT where developers can optionally track an SVN repository via GIT and make their changes in GIT allowing others to fork their code.
Stoyan Stefanov
- http://tools.w3clubs.com/ext/
- Let me know once you have the list of extension points and the other options and ** I can update the tool, then send you the code to add to SVN. The tool is actually pretty simple as you can guess, I have a bunch of files (install.rdf, js, xul and so on) as templates and then the tool simply writes new files by replacing the values in the templates with values from the web form. Then zips the result.
- One thing I would like to keep is the simplicity, because the idea is to make it easy for people to start and not to scare them away with many questions in a form. So maybe step one could be the simple questions that are essential for a new extension. Step 2 (or even 3) can be marked "advanced" and optional.
- The new YSlow extension will also allow extensions, so being able to leverage the Firebug work will be a great way to get developers started.
- Whatever you decide, I can contribute time/code to this project, just let me know what I can do to help.
Honza
Since there is several great goals, I think we should outline some stages how to reach them step by step. The best would be probably the next conf call (12/16).
I really like the idea of having a tool (presumably a web page) that makes possible to simply setup and generate a skeleton of an entire sample-extension package.
Since there is already bunch of options (and I hope there'll be even more in the future), I think that entire setup process could be separated into more steps/pages. Something like a wizard that is used to generate projects/plugins in today's IDEs (Aptana, NetBeans, Visual Studio, etc.).
Roughly speaking:
a) Extension type - (Firefox, Firebug, Prism, Fennec, etc.) in case we want to support more target applications. However, I guess we want to focus mainly on FB extensions for now.
b) Extension info - (name, id, description, home URL, creator, etc.). This is covered by the current implementation of Stoyan's page.
c) General structure - setup for: a panel (name, title, default options+handlers, toolbar buttons+handlers, is it searchable and editable), module, localization, panel-enablement (even if these APIs can change yet), custom CSS style-sheet).
d) Domplate - setup for simple Domplate template that uses anything from the current page and generates default example output to the panel (+ an example of a click handler, + support for context menus).
e) Extension Points: setup for various listeners that can be registered within existing Firebug UI (Net panel, XHR Spy, Console panel, HTTP observer), options for Firebug customization (e.g. Net panel).
f) Firebug Tracing: Support for Firebug tracing console. This option could generate bunch of FBTrace.sysout calls at right places in the code. This would enabled to see when certain methods are called and in which order (for example initContext, showContext, destroyContext).
I think that reasonable first step would be to put down (I can do it) list/doc (+ code examples) for all existing extension points, so we know what to actually generate by such a tool.
Also (I know Christoph won't probably like it :) , but I would like to at least consider whether it wouldn't be better to put all the stuff under fbug SVN (google-code). Thus there would be lower barrier for all Firebug developers to use it. But of course, I am open to a discussion.
Rob Campbell
I mentioned it yesterday, but for reference, here's Ted's Mielczarek's Firefox/Thunderbird Extension Wizard.
http://ted.mielczarek.org/code/mozilla/extensionwiz/.
I like the idea of having custom starting points. We might also want to include extension points on the Firebug menus (both in Tools and under the 'Bugmenu).
Not sure how up-to-date it is.
Google code SVN or even a webapp would be cool. Whichever works. :)
John J. Barton
The overall goal is to provide some level of testing for Firebug combined with its extensions, including Firefox extensions like HTMLValidator which may used with Firebug but not an extension of Firebug. Co-testing would increase the success of extensions and increase user confidence.
A secondary goal is ease of install, anywhere from a list of co-tested extensions to complete installation. This part is more a matter of UI and legal issues.
The basic idea is to have a decentralized development and centralized testing. Extension developers would opt-in to the system (the "swarm") by joining a mailing list and providing a URL for an XPI file. In that XPI file, the install.rdf would include the swarm public key and a URL link to an update.rdf file on getfirebug.com. All of the XPIs for the system would be loaded into Firefox with a beta version of Firebug.
Some testing would be applied and if the tests pass, a new update.rdf would be created for each XPI in the swarm, each XPI would be hashed into the update.rdf and these files would be signed with the private swarm key and finally the resulting update.rdf files would be posted to getfirebug.com/releases.
If the testing fails, some recovery procedure has to be applied. One can imagine some kind of semi-automatic serial triage to identify the extension conflict, but a more practical alternative may be simply to debug the problem manually.
The perfect testing process would install the extensions the same way users will. That won't work since the update.rdf can't be published until after the test. So the alternative is a fresh install of all of the extensions, probably by running a script that downloads them (I guess this would be a javascript that could also be available to users).
Firebug's fireunit tests could be applied and the visual sanity checks performed on Firebug alpha and beta releases. Note that this co-testing is limited to verifying that Firebug works when all of the extensions are loaded. Individual extensions are responsible for testing the functionality of their extension.
End users would install Firebug and the extensions either manually via a set of links on a web page or some other way to be developed (Firefox's multiple XPI packaging could an option if re-distribution of the packages does not cause legal issues). As updates become available their browser would contact getfrebug.com for update.rdf, then be redirected to the original developers link to obtain the code. That would mean that extension developers would only be able to push updates after the swarm test passed, but they can opt-out of the swarm at any time by taking down their XPI.
At the beginning a large part of the centralized testing will be manual, so one of the risks in the project is discovering that I don't have or can't devote adequate time to this work. Its possible that conflicts could be quite a bit of trouble to resolve, but then again we are probably in the best position to track down problems. If few problems come up, then the entire exercise is mostly about co-advertising extensions. If multiple problems come up we are making the extension ecosystem stronger by fixing them. Either way its not a bad outcome.
To implement this:
- firebug swarm newsgroup, limited access mailing list for resolving problems (wait for system to be prototyped)
- swarm collection script: given a list of XPIs, install all by default with UI to skip some (for triage and for end-user opt-out).
- swarm test script: some extension of fireunit tests for firebug
- swarm deployment: adapt mozzipper to create hashed, signed update.rdf. svn commit would post these to getfirebug.com
