I should be able to write an XPI installer script that will search for a certain string in a (usually text) file and insert/replace data in that file, based on the location of that string. For example, I may search for startup() in navigator.js and insert a call to a function I want to run in another JS file which I would have to insert a line to import, etc. This would be very important to people writing add-on packages to customise Mozilla.

Interesting idea. Maybe we can incorporate Larry Wall's patch code, 'cause I'd hate to duplicate it. Would there be licensing issues? Text patching XUL files will probably not turn out to be very useful, because chrome is going to be packaged into zip archives soon -- so then you'd need a tool that unzipped, patched, and rezipped. Oy! Maybe the current binary patching would be good enough, but it's fragile in the face of version differences.

wow...zip files? I thought it was going to be jar. And anyway, extracting a single file from a zip, patching and putting it back shouldn't really be that time consuming, considering these files would be read/extracted when moz uses them anyway. I think it will turn out to be useful for companies who want to overlay the menu structure and/or modify it, as Mozilla is _suppposed_ to be easily customisable. If we don't provide the tools for such relatively-simple customisation, we can promptly stop claiming big things as regards the customisability of Mozilla. Just having XUL there doesn't help if there are no tools built-in to modify it with relative ease.

I have no idea why people are calling it ".jar". A .jar file is simply a .zip archive with a different extension and some signing meta-data. Our chrome archives are not going to be signed and will not contain the extra meta-data so IMHO giving them a .jar extension is plain wrong. If chrome *were* signed this technique would fail horribly as modifying a file would break the signature. You'd end up having to do a binary patch of the entire archive: you'd have to update the signature files when you touched the signed chrome files.

ok, cool. If we're not going to have signed files, then this should be relatively easy. I hope it will be taken off 'Future'.

"Future" just means I personally will not be able to deal with it in the foreseeable future, i.e. while swamped shipping Netscape 6.0. IMHO this is the appropriate classification for a feature request at this point. In a future version, or if you can find someone else to do the work...

well, can we put helpwanted on this then? You were saying something about Larry Wall's code? If you give me more details, I could find out about that. I would do it, but my c++ knowledge is next to nothing :(.

Adding helpwanted keyword. Given that Moz will contain code for dealing with .zips/.jars, we should be able to use that. I don't think we can use Larry's patch code, as it seems to be under the GPL (at least, he hasn't maintained it for ages, and GNU now are maintaining it). We could try and find a pre-GNU version, but I doubt it would be much good comparatively. Will Mozilla's new dual license permit the incorporation of pure GPL code, or not? Gerv

Mozilla currently contains code to *read* zip archives, but not create them. Other people have requested it so creating archives may be generally useful (although others complain about feature bloat). mozilla.org has no plans to accept GPL-only code.

nominating nsbeta3, because (for the reasons discussed above), I think this could turn out to be very useful.

Unfortunately nsbeta3-: this is not the time to be adding new features. At least not Netscape employees; this could make a fine project for someone who's interested.

This should not be allowed IMO on Mozilla XUL. Overlays are going to be enhanced to do all of the things a patch might need to do, and altering the original XUL prevents the user from reverting changes and restoring defaults. IMO this is a dangerously bad idea.

Closing as WONTFIX; use overlays instead. Gerv

Marking Verified.