Innocence (of scripting) lost

For the last few months, I’ve been doing Verbosio development based on Mozilla
milestones (as opposed to the trunk). Each of the last few milestones has
brought a change which impacted Verbosio. I didn’t spot any for 1.9a7, and I
thought the migration would be nearly painless.

There was a change impacting Verbosio – and depending on the point of view,
the result is either trivial or damaging.

Several months ago, I blogged about XPCOM class invariants for JavaScript
using the nsIScriptableInterfaceInfo interface. The code for this interface
lives in extensions/webservices… which was shut off with SOAP. Oops.

I filed bug 392004 to resurrect it, but even as I do this, I realize there’s
not much use for having it on by default. (Otherwise, people would have
complained about it much, much sooner.) Sure, it benefits me, but between one
developer’s convenience and millions of users’s Firefox installs, a few extra
kilobytes are expendable. Even for XULRunner 1.9, I expect it would be a tough

The simplest solution, of course, is to disable the invariant contracts when
they can’t be built. I should’ve done that in the first place. Invariants,
though, add valuable sanity checks. So to get them back,
I have to compile the scriptable interface info code as part of Verbosio.

There, I said it: “compile”. With that one word, I have overshadowed one of
those little goals I had for Verbosio from the beginning: that you could take
an unmodified XULRunner and run Verbosio. It’s ironic, considering Benjamin
Smedberg quietly taught Firefox how to run XULRunner apps like Verbosio – and
thus expanded the potential user base by a factor of five thousand. (I meant to blog about that in particular.)

Naturally, I can ship the necessary .dll, .so or .dylib files with Verbosio
– just pre-compile them. By all rights, I should. I’m not sure if I can ship a
DLL file compiled from Visual C++ Express, though – which means spending a few
bucks getting Visual Studio.

I have only myself to blame for all this – not just for relying on an
extension, but for not planning for C++ code to enter the picture. Sure, it sounds like a lot, considering this is for debug-only code. As a developer, though, I like having as much debug code on as I can get while I’m crafting the app. Live and

5 thoughts on “Innocence (of scripting) lost”

  1. I would be surprised if you couldn’t find a compiled web services extension somewhere on the web, and it shouldn’t be too hard to ship the web services extension along with Verbosio, right? You’d only have to get it once since you’re not modifying it, and then just include it along with everything else.
    (From Alex: Normally, I’d agree with you. In this case, though, there were issues with the code in that extension besides interfaceinfo.)

  2. Back when Mozilla/Firefox was a (mostly) unknown project, removing public features did not have a significant impact. As Firefox becomes more popular, this will reverse. I hope Mozilla does not make it a habit of removing supported features — or developers/companies are going to be reluctant to design software that may not work in the future due to a seemingly arbitrary decision to remove functionality.
    (From Alex: I disagree totally with this in the context of what was actually removed. SOAP support in Mozilla was buggy, and did deserve to be removed. I just caught some of the fallout, that’s all.)

  3. I’m assured that it will, even if the executable is built with wacky optimisation settings that aren’t available in the express compiler.
    It’s probably a good idea to make sure both build environments are at the same service pack level – if it’s built using visual C++ 2005 SP1, you’ll need to use visual c++ express SP1.

Comments are closed.