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