What are the advantages/disadvantages of using a jar archive in an
extension's chrome/ directory over simply leaving the directory tree
unarchived? More specifically, are their security or performance issues
one needs to take into consideration?

PS: I am speaking mainly of extensions that are small in size say, less
than 60KB.

TIA

--
Sailfish - Netscape/Mozilla Champion
Netscape/Mozilla Tips: http://www.ufaq.org/ , http://ilias.ca/
Rare Mozilla Stuff: http://www.projectit.com/

On 2/12/2010 3:30 PM, Sailfish wrote:

For an extension developer, the directory tree wins hands down. A small
performance advantage for reading out of the jar is hardly matched by
the confusing it adds to development.

For the average user with a few extensions it may make more of a difference.

jjb

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

loading many small files from disk is significantly slower than loading
one big file - one of the things the Firefox developers were doing to
improve startup performance in Firefox 3.6 was moving more and more
files into jar files. For a small extension I don't think it's too much
of a problem, but there are people with 50 or more extensions, maybe it
helps them a little.

Having no jar makes packaging slightly easier, but there are scripts [1]
 taking care of that by creating a xpi with a jar file and automatically
translating a chrome.manifest used for developing (without a jar file).

1: This is what I am using:
http://code.google.com/p/organize-search-engines/source/browse/trunk/...

- --
Malte Kraus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt17N4ACgkQU9AX8TCX8ctrhgCfbusUOKP9V/ZVZRiaH+JhWB1H
Kp0Ani7NvheOVFR8Oe7ejjbyBP1/SCh8
=aUZt
-----END PGP SIGNATURE-----

I too tend to leave the dir tree unarchived, though, if we want to find a
point in favor of jars, consider that if you have very long names (this
happened to me because I had java class files in the extension and the
package named burned out lot of the path space ) you may go over the 255
chars allowed for addressable file paths. This resulted in installation
errors which were not so easy to discover. Packaging all of those class
files in a jar eliminated the problem at the root...

Armando

[mailto:dev-extensions-bounces+stellato=info.uniroma2...@lists.mozilla.org]
On

On 2/12/2010 3:30 PM, Sailfish wrote:
All excellent responses, thanks for the information. I think I have a
better handle on when I might wish to use one or the other methods.

--
Sailfish - Netscape/Mozilla Champion
Netscape/Mozilla Tips: http://www.ufaq.org/ , http://ilias.ca/
Rare Mozilla Stuff: http://www.projectit.com/

From a end user perspective. I have several different profiles, several
of Firefox, SeaMonkey, and of Thunderbird. Some of these profiles can
have up to 60 extensions installed. I back up my profiles twice a day to
different external hard disks and I notice that for unjarrred extensions
my incremental backup has to stat each file in each extension to
determine of it needs to be backed up, while for jarred extensiones it
only has to stat one jar file. The former causes a significant (it's all
cumulative) hit on my backup time.

From an extension developer perspective, I perfer jarred extensions. I
got into extensiond development by joining the Flashblock team and I
inherited some scripts that automated the jarring process so it's
basically all transparent to me.

From a SeaMonkey developer point of view I should point out that on
Mozilla trunk (Firefox 3.7a1) the platform developers are moving
aggressively towards jarring *everything* into one or at the most two
large jar files. It appears that on slower platforms such as Wince
opening handles to files is a slow and expensive process while mmaping
already opened jar files is significantly faster. Now consider someone
with 60+ unjarred extensions in his profile on an underpowered netbook
running some version of Windows and imagine that Firefox has to stat
every file in each extension on startup. The hit on the Ts performance
would be palpable.

The Fennec team is basically terribly unimpressed with how excruciating
slow Windows Mobile is in this and other regards and if you are writing
an extension for Firefox Mobile (Fennec) you should definitely jar your
extension. Your users will thank you. Fennec developers will thank you.
Plus you get lots of Karma points.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <philip.c...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]If all goes well, you've overlooked something!
* TagZilla 0.066.6

On 2/12/2010 8:18 PM, Philip Chee wrote:
I hadn't considered the backup implications for those who do it often
such as yourself. I'll keep that in mind if I ever develop any large
extension. btw, I do archive my chrome/ directory tree for my theme
packaging since themes contain a significant number of files. After
reading this, I'll ensure that I continue to do so with theme packaging.

Most of my add-on activity evolves around themes but I do have a few
extensions that I keep maintained. My development environment is Windows
and I take advantage of the "Adding Extensions using the Windows
Registry" discussed here, http://tinyurl.com/ykekh2q. In that way I am
able to make and test changes live, without the need to package/install
the modified files.

Hmm, that's very interesting. Does Mozilla open the jar file into
allocated memory and thereby removes the need to do a file stat? If so,
then wouldn't there be a performance trade-off between allocating a
significant amount of memory to cache the extensions chrome/ trees
versus the hit for doing file stat calls considering that most hard
drives have many megabytes of internal cache?

I'm not doing any work on stuff for Windows Mobile but thanks for the
heads-up in the event that I do find a need.

--
Sailfish - Netscape/Mozilla Champion
Netscape/Mozilla Tips: http://www.ufaq.org/ , http://ilias.ca/
Rare Mozilla Stuff: http://www.projectit.com/

Well that does make things easier. I did this for XULMine (develop
unjarred, then create a jarred extension).

This was actually to do with the XUL cache; Firefox would record every
chrome URL (up to the jar if present) and stat it on each restart to see
whether the XUL cache was out of date, even for files that never got
cached! It doesn't do that now (I'm not sure quite when it got turned
off), so if you edit your extension without clearing (sorry I forget
how) or disabling the cache the changes won't take effect even after a
restart.

--
Warning: May contain traces of nuts.