I'm not a skilled C programmer but I do know what to try and do, use as little memory and try not to repeat steps.
Running manifesto twice creates manifest.mf and zigbert.sf twice. I've been trying to go through the code to figure out other ways to reduce repeated code. So I have some questions of my own. I have figured out a few different methods that would get the job done.
1. Is running manifesto twice, once before zip file is opened so the zigbert.sf is created which is required to create the zigbert.rsa/dsa file? If so then I have little work to do. But of course the easy way out is hardly ever the "right" way out.
2. If if manifesto being run twice is not acceptable. The best other possible solution I can think of is to set another variable zip_only that would in manifesto tell it to run through the files to be zipped only. This would call up manifesto_fn in which would also have another if for the zip_only variable. If it exists just zip the files that need to be zipped. manifesto_fn does some verifying on what files actually need to be signed and zipped. This method to me seems a bit messy compared to the way the source syntax already is.
3. Create a temporary file or array of files that would need to be added to the archive. Doing this would be in manifesto_fn check if -X is set. If so then create list of files that need to be added to the archive and not add them now. So manifesto only gets run once, the manifest.mf and zigbert.sf only get written once, and less code is changed only new code is added basically. The only thing is I dont quite know off hand how much code would be added.
3.a If file method is used it would mean more disk activity but a method I'm confident I could do.
3.b Using the array method or something like that I'm not so sure off. I dont see any arrays being used in the code. I'm mainly a PHP programmer and am used to using array's for many things.
Also IMO, Does it really matter? This hasn't really been updated in many years and just adding the option and having it coform to your 3 questions is more important then a few more kilobytes in file size or a few miliseconds longer run time for smaller projects?
I've run some tests on signing large archives and the difference between signing an XPI with method 1 and creating a regular archive without the -X option is roughly 4 seconds longer. This was a 56 directory tree that went as far as directories deep, 981 files and 138 megs. The run times were roughly 1min 4 seconds using the -X option and roughly one minute running without the -X option. The bulk of the time used is when the files are getting zipped up.
I also tested the -J option for signing Javascript that also uses the SignArchive function I made the changes too. I fed it 4 HTML files set up to archive the javascript contained within. Nothing large tho, just my Al Bhed translator javascript edition and my drop down menus from my site. It created the archives just fine.
Let me know what you think about the different methods. Personally I dont think the running manifesto twice only when signing with the -X option is a bad tradoff. If you others think it is I'll benchmark the other methods.
All methods I mentioned will answer all 3 of your questions with a yes. The 3rd method would involve alot more code to handle the error's it could incur.
Right now it's 2:15am and the girlfriend is already in bed wondering when I'm gonna stop working on this.
I also did some looking into adding longname options. I dont think it would be to hard to add them and maybe even split off into a different function and have it called by both input methods, commandline or config file. This way the config files would also support the shortname options.
Jeff Klawiter
Nelson Bolyard wrote:
Jeff
The idea of a command line option to produce XPI files that are acceptable to the current mozilla browsers is one that could become an acceptable contribution to mozilla. I *encourage* you to pursue this until your contribution is accepted. Fame! Glory! :)
The best and right way to do that, IMO, is to register with bugzilla, then create a bugzilla "bug" (enhancement request) about this, and attach your source diffs to that bug as an attachment in bugzilla. newsgroup postings get lost and forgotten. Bugzilla bugs keep showing up in queries until they're fixed. :) If you're interested in that, I can provide you with a number of tips on how to make that go smoothely. Feel free to write me (you can demangle my email address above).
I believe that your patch should be coded to have the effect then when the new -X option is NOT supplied, the output of the tool is the same as version 1.3 produced before; files get output in the same order, values computed in the same way, same error messages for missing or unwritable directories, etc. The behavior should only change when the -X option is present.
So, now I have some questions about your new version of the code:
a) when the -X option is absent, does the program produce XPI files with the same content in the same order as version 1.3 did?
b) when the META-INF directory is unwritable, or doesn't exist and the parent directory is unwritable, and -X is absent, does the new tool produce the same graceful error messages as version 1.3?
c) same as question b, except -X is present.
If the answer to any of those questions is no, then please take another pass on the patch. Thanks.
/Nelson
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
