Lots of discussion going on recently about the affect of 6 week development cycles on binary XPCOM components in add-ons. I don’t want to re-hash those discussions, but Daniel Glazman brought up an interesting point in a comment on Wladimir’s post. Wladimir was suggesting binary component developers start moving to js-ctypes. Daniel pointed out that there are two classes of binary XPCOM components:
- XPCOM wrappers around 3rd-party binary libraries: We use this model for exposing external binary functionality into JavaScript so add-ons and applications can access the libraries. Using js-ctypes should provide a simple, non-breaking way to expose the libraries. You create a simple JavaScript wrapper in a JavaScript XPCOM component. We need more examples of using js-ctypes to do this, but it works.
- Pure binary XPCOM components built only using the Mozilla platform: Sometimes the functionality you want to expose is actually locked away in the Mozilla platform itself. Maybe there is no public nsIXxx interface or the existing interface has a [noscript] attribute on a property of method. This model shouldn’t be required anymore, in my opinion. Mozilla is pushing JavaScript based components and we should be exposing as much as possible to chrome JavaScript. I would encourage add-on developers to file bugs and lobby to expose binary-only parts of the Mozilla platform to chrome JavaScript.
JavaScript ctypes has come a long, long way since it was started back in 2007. Let’s start leveraging it more. The ctypes model has been used quite effectively in other languages.
Have you guys reached out to the folks that use binary components to find out why they use them and to help them make the migration?
I realize js-ctypes has been around for a while, but there has to be a reason why people are still using binary components right?
@Michael – I don’t know if Mozilla has been reaching out to binary component developers. Hopefully, Jorge or Justin can provide that answer. Not trying to slight anyone, but I imagine inertia (or lack of it) is the biggest reason for not moving to js-ctypes. If something is currently working and switching will not be free/cheap then why do it? 🙂
I’d suggest the problem lies elsewhere. The developer.mozilla.org documentation has an extensive guide on XPCOM which says nothing about js-ctypes being preferable:
https://developer.mozilla.org/en/creating_xpcom_components
The “Building an Extension” documentation includes a section on XPCOM components and none on js-ctypes:
https://developer.mozilla.org/en/Building_an_Extension
The AMO Extension Development documentation page (https://addons.mozilla.org/en-US/developers/docs/how-to/extension-development) links to an article about creating custom extensions with C++ code, which only mentions XPCOM and does not include any information on js-ctypes (and which apparently hasn’t been updated since FF 1.5):
https://developer.mozilla.org/en/Creating_Custom_Firefox_Extensions_with_the_Mozilla_Build_System
In fact, the d.m.o page on extensions has nothing on js-ctypes at all:
https://developer.mozilla.org/en/Extensions
Want extension authors to stop writing code with XPCOM? Stop telling them to! Mozilla should lead a coordinated effort to update their documentation so addon developers know exactly how to write future-proof extensions. Otherwise, don’t be so surprised when they build with XPCOM.
@Alex R – Easily remedied, but the inertia problem will still exist. Also note, XPCOM using JavaScript is still OK, so all those docs covering the basics of XPCOM and how to implement XPCOM using JS are still relevant.
PS: js-ctypes are preferred to binary XPCOM! You heard it here first 🙂
There’ll certainly be inertia, but if Mozilla could respond to the “my addons will never be compatible ever again due to your evil release schedule!” types with “here’s instructions on writing an addon that will stay compatible easily”, the inertia would be much easier to fight.
Particularly if MDN had a “Transitioning to js-ctypes” article.
This is very wrong.
First of all, add-ons should be first-class citizens of the Mozilla platform. Binary XPCOM is a big part of it, and add-ons should be allowed to extend it.
Secondly, binary components are not there to just use obscure hidden bits in the platform, they use ALL of the platform, including platform-independent file access, XHR, observers, etc. There are a myriad of advantages that XPCOM offers over building independent libraries. It’s not a simple matter of telling people to switch. It not easy at all.
Many developers are aware of js-ctypes and have concluded it is insufficient for their needs. Just look at Nils’ comment on my post.
js-ctypes is a great solution if your component is an independent library that needs access to a system feature that isn’t accessible through XPCOM. It is not enough for the majority of other cases, where interaction with other XPCOM components is necessary. I do recommend developers to use it when they can, but saying the binary XPCOM isn’t required for add-ons anymore is wrong wrong wrong.
Mark, I’d be glad to make everything with JavaScript, but I’m afraid it’s currently unfit to replace binary components. What about subclassing thread-safe platform components?
http://hackademix.net/2011/07/14/killing-binary-xpcom-in-add-ons-is-javascript-fit/
@Jorge – Yes add-ons _are_ first-class citizens. Binary XPCOM is certainly part of it, but not the biggest part of it. And now that binary XPCOM is extra effort, I think we should be showing people how to do it an easier way.
Second, I never mentioned “obscuring” as a feature of binary XPCOM, but now that you mention it, people do use it that way. Creating a non-XPCOM binary component can achieve the exact same result. Use js-ctypes to wrap and expose the binary library and you are good to go.
I totally disagree about the “myriad of advantages” of binary XPCOM. It’s a means to an end and that means is now too costly for most developers, Let’s find an easier way.
If js-ctypes is lacking, then let’s make it better. We are not the first group to start using the ctypes concept. If we have areas in the Mozilla platform that make it hard to move away from binary XPCOM, we need to fix that. Giorgio mentions thread-safe platform components. We need to fix this.
We must move forward. The writing is on the wall for binary components.
@Giorgio – You have a good point about thread-safe subclassing. We need to way around that.
Mark, with all due respect, I disagree 100% with you here. I think you don’t understand why binary XPCOM components built through the mozilla build system are needed for 3rd-party companies like mine: the browser IS A BROWSER. For a tool like mine, it lacks APIs that _could_ be here but are considered as bloat from a browser’s perspective. I’m fine with that as long as we have a binary extension system. These APIs are hard to implement in JS for performance reasons (have to browse the entire style set of a document, lots of tree traversal, etc) or because they need stuff that are not exposed to JS. Such binary-based components should not be needed, I agree; but because Fx is only a browser and does not want to be bloated with all what’s needed by an editor, a video player or editor, an iTunes clone and more, they are still _absolutely_ needed.
And I agree 100% too with another commenter: js-ctypes are just not enough for 3rd-party standalone app authors’ needs.
Also, note that if you need an XPCOM interface and have existing binary code, it should be easy to do a JS XPCOM component (that can easily stay compatible when the ABI breaks) and have that load/run your binary code via js-ctypes. I’d prefer that any time if I would do add-ons that have binary code.
Also, the story that you need binary code because JS is too slow is a myth in more than half of the cases nowadays. But I surely understand that some of those cases remain (and we need to fix those as much as possible) and even more understand that rewriting existing code into JS just for the sake of rewriting it is often not feasible. Wrapping that binary code into a JS XPCOM component via js-ctypes is easier than a rewrite and spares you recompilation every six weeks.
I totally agree that we must move forward. I also agree with other commenters that the needs of implementors using Firefox as a platform (like myself) are not currently met by js-ctypes. There’s just too much goodness locked up inside of Firefox that can’t be gotten at without using binary XPCOM APIs.
Making all of this possible via pure JS should absolutely positively be a goal. Being a lot closer to achieving this goal should have been a prerequisite to making extensions with binary components require redeployment every 6 weeks.