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 sell.
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 learn...
Posted by WeirdAl at August 16, 2007 7:25 PMI 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.)
Posted by: James Justin Harrell at August 17, 2007 2:59 AMBack 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.)
Posted by: Aaron at August 17, 2007 7:56 AMSeems you can distribute a DLL built with VC express. From http://msdn2.microsoft.com/en-us/express/aa718399.aspx :
4. Can I use Express Editions for commercial use?
Yes, there are no licensing restrictions for applications built using the Express Editions.
(From Alex: Okay. But will a DLL from VCE work with a XULRunner built with VC++ 8?)
Posted by: Asztal at August 17, 2007 5:47 PMI'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.
Posted by: Asztal at August 18, 2007 7:45 AMThe express C++ compiler is exactly the same as the Pro these days, optimization and all.