I didn’t really like this very much. JSLib has been useful to me in the past. But when I thought about it, the only thing I used JSLib for was its file I/O utilities. These utilities should be used from chrome (and I abused that in my file search components).
Plus, I’m a much more experienced developer than when I first started with Abacus over four years ago. The Mozilla code base has similarly improved, and I just felt I could do the same job I was asking JSLib to do, with less (and cleaner) code.
Besides, if you’re going to replace a library with one of your own, you should add value (not just cut costs).
I decided to write a library that, in theory, would be able to read and write to flat files, zip archives… and zip archives within zip archives. Think JAR files inside a XPI. Then, to make sure that I did it right, I decided to write a xpcshell test case for the module. (Yes, you can do that. The test harness doesn’t care whether you’re testing components or a .jsm file.) After a couple of days, I came up with FileCommon.jsm and test_FileCommon.js.
(The key is in FileCommon.getFile(), near the end. It takes multiple arguments, beginning with the path to a zip archive in the operating system, then an entry inside the zip (which is also a zip), then an entry inside the second zip archive, and so on.)
I’m sure there are bugs in this implementation. Right now no code in Verbosio uses it yet, and as I work on replacing JSLib with FileCommon.jsm, I’ll continue to add to the module. Eventually, I may make it a standard components module with new interfaces. Like so much else in Verbosio, it’s right now a proof-of-concept.
With JSLib, the time has come to move on. XUL Widgets will also fade, as I absorb its efforts into the Verbosio project directly. XUL Widgets (and Verbosio) doesn’t have any other customers, anyway, so centralizing under one roof makes sense.
Thanks for getting me started, Pete.