Replacing JSLib in Verbosio

I came to an unpleasant decision last week. While working on reorganizing Verbosio’s source code, I realized that JSLib should not survive the transition.

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.

I’m not saying JSLib is a bad library or a bad idea – far from it. I’m saying what I needed from JSLib is too small to justify having it around. Libraries for Mozilla are a popular idea – FUEL, STEEL, and JavaScript modules (.jsm) come to mind.

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.

One thought on “Replacing JSLib in Verbosio”

  1. I love jslib. Thats funny I just started a new XULRunner project, and tried to get it rollin’ without jslib too, using JavaScript modules instead. Didn’t get too far, the JSMs behaved differently in some areas where I wasn’t expecting, and I lost a lot of convenience jslib had.
    So I’m still using jslib and loving it. 🙂

Comments are closed.