According to Mark Finkle, who comments Daniel Glazman’s reply to Wladimir Palant (and the discussions goes back many hops yet)

[…] there are two classes of binary XPCOM components:

  1. 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.
  2. 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.

I fully subscribe to Mark’s opinion about the second category, but unfortunately this is not just as simple as removing the [noscript] flag from interesting APIs (and introducing some wrapper types to make it possible).

What about subclassing a platform component in JavaScript? Of course you cannot as long as its interface expose any [noscript] member, but you cannot either if it happens to be marked as thread safe. That’s the case of the DNS Service, which can be called from any thread. I’ve considered wrapping it in order to satisfy a strict requirement of ABE’s (intercepting HTTP requests after DNS resolution but before any data is sent to the web server) in a less hackish way than today, but this would currently require building a XPCOM binary for each supported native platform. That’s a trouble I’d gladly spare myself, and Mozilla’s making it unsustainable anyway. So, does Mark’s statement imply that the relatively recent ban on multi-threaded JavaScript might be reconsidered? Is this even possible in this brave JSCompartment new world?

7 Responses to “Killing Binary XPCOM in Add-ons. Is JavaScript Fit?”

  1. #1 Daniel Glazman says:

    Two things: first, the stylesheet (colors, background, font weight and font size) of this page makes it _extremely_ difficult to read for people having contrast issues…

    Second, I think you don’t understand why binary XPCOM components built through the mozilla build system are needed: 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. 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 stille _absolutely_ needed.

  2. #2 Giorgio says:

    @Daniel Glazman:
    1) I’ve been dreaming of a restyling of all the sites of mine for a long time, I really wish I could find the time :)

    2) With JS getting faster and faster, I’m not sure I buy into the performance argument. At any rate, the use case of adding capabilities on top of the platform seems one which can be served, at least in theory, by a (better, more polished and less buggy) js-ctypes. At any rate, I was trying to point out that a de-facto deprecation of 3rd party binary XPCOM is absolutely premature at this moment, albeit with arguments different than yours.

  3. #3 Björn says:

    Isn’t the deprecation also necessary because of e10s?

  4. #4 tommy says:

    @ Daniel Glazman, Giorgio:

    "the stylesheet (colors, background, font weight and font size) of this page makes it _extremely_ difficult to read"

    "I’ve been dreaming of a restyling of all the sites of mine for a long time, I really wish I could find the time :)"

    No problem! View > Page Style > No Style. Been doing it for a long time. Try it - incredibly easy to read! ;-D … however, the recaptchas are driving me blind, seemingly always the second of the two words. There must be *some* better way that a human can read more easily, but a bot can’t… :(

    Maybe someday, someone will invent a "text-only" web page.. oh, wait, they had that in the 1990s ;)

  5. #5 a says:

    Hello everyone.

    A week ago this line started to appear in my httpd log several times a day:
    [2011-08-07 13:11:05] 192.168.0.1 - - + 200 1293 "GET / HTTP/1.1" "-" "Mozilla/5.0 (ABE, http://noscript.net/abe/wan)"

    192.168.0.1 is my router (ASUS RT-N16), this IP shows when someone from our LAN goes to its MAN or WAN port, which gets port forwarded to me.
    If it knew any domain name, it would get 8KB page, not 1293, so it does not.

    I am not around at the time it happens, so I went to the URL it gave, to ask what it can be and if I should worry at all.

  6. #6 a says:

    Actually I think I got it. You may delete this message.

    Someone from MAN browsed with my LAN proxy and this ABE thing.

  7. #7 Thomas Ludwig says:

    @Daniel Glazman, tommy: Until Giorgio finds the time to change the style, Stylish is your friend. Create a new user sytle like that one:

    @namespace url(http://www.w3.org/1999/xhtml);

    @-moz-document domain("hackademix.net") {

    * {
    color: black !important;
    background: none !important;
    background-color: ghostwhite !important
    }

    a:link { color: mediumblue !important }
    a:visited { color: purple !important }
    a:hover, a:active { color: red !important }

    }

Bad Behavior has blocked 33516 access attempts in the last 7 days.