> > archiveDir = dirGetParent(archive); > How did you find that one? only File.dirGetParent is documented.
http://developer.netscape.com/docs/manuals/xpinstall/File3.html#997889 I was looking at the Syntax section. BTW: I've found that Netscape site to be "annoyingly" helpful. Helpful, becaue I've managed to piece together a lot of things over the past week - annoying because things don't work "quite" as documented and I've had to fuss over details. In fact, in general, I've yet to find any good simple reference for working with XPIs. Sites like the above I can eventually figure out (since I've worked with other programming languages) but there is an absence of good solid examples - as well as any kind of tutorial on linking in the XPI specific commands to the general JavaScript lanaguage (something else I've never dealt with). > > However, now I've discovered something even MORE annoying. APIs are > > not actually decompressed to the file system - they're only stored in > > memory. > > I don't know what this means. Do you use API to mean file? When you "execute" an API that you've downloaded, you'll find [filename].xpi in the XPI's archive directory. Just the XPI, not the decompressed files. Any work being done with files *inside* the XPI are done in memory. (So, when you refer something inside the XPI it doesn't first (that I've seen) decompress that file/folder to the filesystem.) > addFile() and addDirectory() are used to get files out of the .xpi archive > and placed on disk. Anyway, yes, I've discovered the above. > It's complex because you're trying to do something that not only have we not > needed to do, the chrome folks fairly explicitly want you NOT to do. Why Oh. <grin> > libraries: tested and created as a whole. The approved method for altering > chrome on the fly is external overlays. Right, I'll now start investigating that as an alternative to what I've already done. (Which, in the final analysis, seems to be fruitless anyway since I can't use that external archive utility to modify the contents of a .jar that's in use.) > work. But once the floodgates open it won't be just you. Everyone will make > their changes assuming an unchanged comm.jar and pretty soon you've got a > conflicting, unworkable mess. I'm not actually touching comm.jar - just modern.jar and classic.jar to change a couple of icons used. But I see your point.
