I’ve just rolled out a small update to the interface cross reference, nothing major, just fixing a few bugs and I’ve put up what looks like the final set of interfaces for 1.9.1b2.
I’ve now figured out the best way to gather the interface lists and so the cross reference now includes all interfaces used in all 3 major platforms of Firefox. It is relatively simple for me to add the interfaces for other applications now but this got me thinking about what kind of uses people are making of this and how the multi-OS, multi-app interfaces should be presented. A few ideas came to mind:
- App developers probably just want to see the interfaces in their app, either only those that appear for all operating systems or those for a specific OS in some cases.
- Add-on developers probably want to see some kind of shared set of interfaces (what you might call gecko/toolkit) that appear for all apps they are targeting, unfortunately this changes depending on the set of apps. Again they probably want for all OS or for a specific OS.
- Maybe I shouldn’t even bother doing anything and just include a note in the interface display about where the interface actually exists.
I’m sure other people have other ideas of how it might work, any suggestions?
I forgot to add to my last post some information about what I currently had in mind to improve about the API reference I’ve been working on. Any further suggestions people have are very welcome, but here is the current few ideas I have.
Currently it only indexes Firefox and Gecko interfaces, in fact it only indexes those used by an OSX build of Firefox. It would be nice to be able to index interfaces for all the main applications and for all the platforms. There are a couple of issues with this. Firstly I’d want the UI to work so people viewing it could select what set of interfaces they wanted to see. Secondly actually building the lists of interfaces for each application and OS is going to be pretty tricky I think. So far I’ve resorted to building Firefox then looking in dist/idl. This works but it is time consuming. Possibly I might be able to come up with some clever nonsense to make the build system only compile idls but we’ll see.
It would be nice to be able to include a list of the component contract ids available in the platform and what interfaces they implement. This is I think pretty difficult to do just by parsing the source files. Potentially a little extension could run in the app and do some looking through Components.classes to find this out. One issue here though is there is no way to tell whether components are services or not so instantiating them is potentially problematic. This is a problem that could be solved by brute force, or maybe doing a special instrumented build.
So those are my main two ideas, if anyone has any suggestions on how to make those tasks easier or for other things that should be there then shout them out.
Since my first announcement about my little api reference tool I’ve slowly been working on updates to make it more useful and easier to navigate around. I’ve now gone and pushed the latest version live. A few of the new features:
- The main and platform lists of interfaces are split by the module where the interface lives.
- Interface lists have a quick filter box, type in it to filter the list quickly.
- Any interfaces used as return types or parameters are now links to get you straight to the information about them.
- Full IDL support so it now lists all the special attributes and for the uninitiated they have tooltips that explain what they mean.
- You can now list all usage of an interface by other interfaces.
- Constants are ordered the same as in the source IDL since they tend to make more sense that way.
- Includes direct links to the source IDL file.
I’ve also updated the database with the latest APIs in 1.9.1b2pre and as soon as 1.9.1b2 is frozen I’ll update it again just to be sure it has the latest versions.
You can also search the API for interfaces. There isn’t any UI for this right now but it is perfectly set up for a smart bookmark. Just use http://www.oxymoronical.com/experiments/apidocs/search/interface/%s for the url and an appropriate keyword and you can do quick searches for substrings of the interface name.
For some time now I’ve been throwing around ideas for new features that we may want for the add-ons manager. After lots of thought and trying to take on board comments from anyone that would pipe up I decided it was high time to put together an actual plan for what features I have decided should be pursued and what order to start tackling them.
The roadmap itself should be pretty self explanatory, just remember that nothing is ever set in stone. I’ll try to keep it updated as things change, features seem less important or new items are added. But for now this is how I see the add-ons manager evolving over the course of about the next year or so, which may be the next two versions after Firefox 3.1.
Obviously the ordering of the goals may not be quite to everyone’s taste, but I’ve tried to strike a balance between getting new features done and getting groundwork laid to make things better in the future. I’m happy to take any comments people might have into consideration for altering the plan, but chances are I won’t be making any big changes unless you have some pretty damning evidence that a change is necessary 🙂
I started a small discussion on the newsgroups the other day wondering about the numbers of API changes that had landed on trunk since 1.9.0. It was a short discussion, maybe partly because all I had to go on were the vague metrics that mercurial could give me. It also evolved a little into a discussion of how add-on developers we’re meant to find out about API changes. It’s true that as developers we are getting better at trying to announce our changes as much as possible, but inevitably we miss some, and if you don’t track the announcements what then?
Yesterday on IRC ted jokingly made the comment that I could use the idl parser than bsmedberg wrote in python a short time ago to find out more about the API changes. I’ve been hard pressed on other work lately so it wasn’t long before the prospect of knocking together a little side project had me too interested to do anything else. In a short space of time I had something that could parse all the in-tree idl files into a sqlite database that I could then query. It wasn’t long after that that I got a small web app written to display the content of the database, but I spent some more time today getting it a bit more useful before I showed it to the rest of the world.
So here it is, the API viewer. You can look at any interface in any of the platform versions that I’ve bothered to scan. And here is the more interesting bit, you can compare two platforms to see what interfaces changed. Not happy there? Well you can also compare an interface in different platform versions in a sort of diff like display.
I should note that it is only indexing the core and Firefox interfaces for now, and it’s close to indexing all of the idl files from the sources, many of which don’t make it into the final build (which makes life interesting as it turns out some of them are invalid xpidl!). So you can’t trust that interfaces you find are necessarily useful etc.
The web app is really a prototype right now. Navigation is probably a bit clunky and it’ll need more work to be really useful but I wondered what other people thought of it. So what do you think? Is it useful? What other interesting information might we be able to grab automatically like this?
Update: I’ve added details of the current trunk, 1.9.1b2pre as of today so you can see what changes are coming since the last beta. Not sure how often I’ll keep that up to date though.
Assuming you agree that paying for some add-ons is ok then you have to ask what we do about people using AMO as a marketing platform. This is a tough question since we risk devaluing AMO as a website if it just gets filled up with adverts. I don’t believe that there is an official policy on this. It is such a rare issue right now that maybe one isn’t necessary, but here are are my thoughts on what such a policy might say.
In order to even advertise a pay for add-on the developer must have uploaded a real add-on. If this add-on is just junk, i.e. doesn’t really do anything and is just a means for getting a page onto AMO, then it should be removed. I have seen add-ons like that (that weren’t advertising anything) getting removed as a matter of course anyway so I think this is already working.
The next question is whether the add-on is a basic version of the premium add-on. If so then I think it is totally fair that the developer can include text in the page to note that a pay for version is available elsewhere. I’m less enamoured with the idea of including screenshots of the pay-for version on AMO. I think regardless of how well labelled they are there is a strong risk of confusing the user there.
Trial versions of add-ons pose a question. Should AMO be allowing add-ons on the site that will intentionally stop working after a period of time, or that list features in menus that only pop up a message about needing to pay to activate? I don’t think so. I believe a user should be safe to download add-ons from AMO that are whole products and they can count on to continue to work.
If an add-on on AMO is unrelated to a premium version by the same author then more care has to be taken with advertising different add-ons on the same page. I don’t see a problem with a short note at the bottom mentioning that other add-ons from the author are also available elsewhere, but I don’t think mentioning what the other add-ons are or what they do is a good idea.
Overall I think short notes are the way forward, anything where the add-on is more of an advert than an add-on in its own right is something that needs to be carefully looked at.
Update: A couple of commenters have raised the question of whether AMO should just include pay for add-ons in its listing, something that I completely failed to consider. I’m not sure which side I am on on that yet. I think if handled correctly it could work, but maybe I’ll think on it and do a follow up post on the subject.
I’m very surprised that many people are questioning whether developers should even be allowed to charge for add-ons. Traditionally it is true that add-ons have been freely available, but I’ve known of pay for add-ons for at least 2 years now (that add-on is still available so must be doing ok) and I imagine there have been some around for longer. Some companys’ entire business rests on their Firefox add-ons. That sort of situation wouldn’t exist if no-one ever paid for add-ons in some way.
I believe that developers should feel welcome to do whatever they please. If they believe their work is good enough to charge for and users think it is good enough to pay for then great. There are probably more funded add-ons out there than most people realise. Charging for download is just one mechanism for recouping some cash for development. I use adverts on my website to help fund some of my development. Some developers ask for donations, others are supported by virtue of their add-on driving traffic to their website. Do you think Google give you the Google Toolbar for free purely out of the kindness of their hearts?
I’m no expert in the matter, but I suspect there would be something seriously wrong with the add-ons ecosystem if it was only populated by free items. I’m pretty sure that people actually getting paid for their work will feel more driven to release higher quality add-ons as well as put more pressure on Mozilla to fix the issues that they find in the platform during their development. This helps all developers, not just those charging their users.
I suspect that people who don’t like the idea of add-on developers making some money out of their add-ons simply don’t fully understand just how much work developing add-ons involves. It takes lots of time and effort to get something to the level of quality you are happy with releasing. Those that aren’t developing for a company are literally taking weeks and months of time away from their friends and family to provide users with something useful. You can argue that if they enjoy the work then they shouldn’t be charging for it, I enjoy my day job yet I still expect to get paid. Believe me that working through all the little bugs your users find but often you can’t see is generally not much fun compared to the actual development of a new feature. Money provides that little extra incentive that might mean the difference between an add-on continuing to be maintained and it dying out.
If you don’t like that a developer is charging for their work, even if the same add-on was previously available for free then I don’t really think you have any right to complain. If you don’t think that what they are offering is worth the price then don’t buy it. I wonder, if you were to try disabling all the add-ons you are using for a day, how many of them would you so sorely miss that you could see yourself paying a small price for them.
The question about developers charging money for the use of add-ons seems to be getting brought up again lately. One of the more active theme developers has started to charge for premium versions of their themes, leaving free basic versions still available on addons.mozilla.org. There are a couple of different issues with this, both of which many users are taking exception to. Apparently once I started writing about this I couldn’t stop so I’ve split this out into a couple of different posts to follow.
Being an add-on developer can be hard work. So many different places to look for information about releases, new features and changes to the platform. How can you be expected to keep up with all this?
Well starting next week hopefully we’ll be taking a big step in the right direction. Mozilla are launching about:addons, a newsletter dedicated to getting add-on developers all the important information they need. There will be announcements about when to check your add-ons against new releases of applications, new features added to addons.mozilla.org, plans for the future that you can get involved with and early warning of API changes.
So what are you waiting for? Go and sign up to receive the newsletter direct to your inbox. We’ll also be posting each issue to a blog but the email is more convenient in my opinion. You can of course unsubscribe any time you like. The newsletter should be out about once a month or occasionally more often if there is something important to announce.
Why not let me know if there are important kinds of news that we should be including in the newsletter.
I know all you extension authors out there have been understandably miffed at the add-on update security bits landing before you could do anything about it, so I’ve pushed hard and we can now make an early version of McCoy available.
McCoy is the tool to use if you are hosting your own add-ons and for whatever reason cannot use SSL to secure the updates. If you haven’t yet heard about the new security restrictions that will be in Firefox 3 or you don’t quite understand them yet then why not skip on over to the vastly improved add-on updates documentation and take particular note of the security section.
So what are you waiting for? Grab your copy of McCoy and get to work securing your add-ons.
I should point out that this is an early version, there are a bunch of improvements that we’d like to make so keep an eye on the homepage and here for updated releases. Also massive thanks to Mark Finkle for getting through the code reviews so quickly.
If you happen to hit any issues using McCoy or just have some ideas for it’s future then please file a bug (searching for dupes first of course!). Given that this is an early release there’s a number of issues already on file.