43393 - implement xap files

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, defect, P3)

Description

[Warren Harris]

(I can't find any of the mail I've sent on this subject, but here's a short 
summary...)

I think we need to implement 'xap' files. This would be use for several 
purposes:

1. Place to specify configuration info for xul-based applications (main xul 
file to load, chrome path, etc.)
2. Replacement for installed-chrome.txt
3. Place to specify what would otherwise be command-line arguments (e.g. for 
mac)
4. Place to list component dlls which are allowed to be loaded by the component 
manager
5. Place for getting debug prefs (log modules to enable, etc.)

The idea is that double clicking a xap file would launch "the mozilla platform" 
with a particular configuration, causing a specific xul-based application to 
come up. The main xul program would render, and the js code there would pull in 
components from dlls, etc.

The format of a xap file would be a simple attribute-value list, where the 
values could be lists:

  main-xul: packages/core/navigator/content/navigator.xul

  chrome-path: navigator.jar
               nav-en-US.jar
               nav-modern.jar
               
  log-modules: nsHttpLog
               
  components: necko.dll
              xpcom.dll
              ...

The list of components which are allowed to load (#4, above) is to restrict dll 
loading for test programs, so that we can more easily determine dependencies 
(e.g. a necko test should only depend on xpcom and intl -- attempts to load 
other dlls should fail).

Note that the ability to parse and provide information for a file with this 
format really has nothing to do with xul. I propose building this facility into 
xpcom simply so that it can be a pervasive way to persist this sort of thing.

Why not use xml? Perhaps we could (or a simple subset) but it seems like too 
much overhead to pull in an xml parser. It's also seems like it would 
be more difficult for installers to generate xap configuration files on the fly 
if they were xml. But I could be convinced.

Xpcom should provide a well-known service which presents an interface to get at 
the configuration information from a well-known xap file (one provided to 
NS_InitXPCOM?). This interface should be some sort of string-key hash table 
where the values are strings or string arrays.

Comment 1

[Warren Harris]

See bug 36031 "Mozilla components cohesion issues" -- why I think explicitly 
stating component dependencies would be a good thing.

Comment 2

[Warren Harris]

Cc'ing David.

Comment 3

[Warren Harris]

I have extended the nsPersistentProperties.cpp syntax to allow properties with 
multiple values, e.g.:

  chrome-path = navigator.jar,
    nav-en-US.jar, nav-modern.jar

We can make a special service that's reads a particular properties file that 
serves as the xap configuration file. 

Cc'ing ftang because nsPersistentProperties is used by intl. Cc'ing rayw because 
he wants to use something simple for the component registry, and I think this 
will work for him.

Comment 4

[Rann Bar-On]

I think this is a great idea, since it would allow far more flexibilty than the
current model offers.  Before JAR files were introduced for packages, an xpi
could, at the user's request, overwrite core xul and js files.  This was a
wonderful feature, since it would allow companies to easily modify mozilla and
very easily install such changesthe  Us.  This is a lot harder now.  I think xap
files will pretty much solve the problem by allowing installation of a set of
xul, js and css files which will, using an xap file, take precedence over
unmodified mozilla files.  This will, in effect, do the same as an xpi
overwriting files currently, but will be much more secure and easily
uninstallable.  The advantages of xap's could be huge, and I think it's very
important that this feature be implemented ASAP.

Comment 5

[Zach Lipton [:zach]]

I feel also feel that this is a good idea, as it would make it easier to extend 
mozilla in new and different ways. I think that this bug should be nom'd for 
nsbeta3, though I highly doubt that it will be accepted, there is always a 
chance :)

Comment 6

[David Hyatt]

That's all well and good, but this should wait until after we ship.  We need 
time to design it and get it right.  This isn't something that can just be 
cranked out.

Comment 7

[Doug Turner (:dougt)]

mozilla is accepting patches.

Comment 8

[Warren Harris]

Before we accept patches... let me just say that I have the diffs in my tree to 
parse xap files. The way I did this was to extend the property file parser & its 
syntax. However, the i18n guys didn't like the fact that I made "," be 
significant in the RHS of property definitions (they wanted to preserve the 
java syntax). Maybe if we can come up with some other separator character, 
they'll be happy.

Also, I'm going on vacation for a week, so I'm not going to touch this until I 
get back. 

Comment 9

[Rann Bar-On]

er, seperation chars....how about | (pipe) or ! (exclamation mark)?

Comment 10

[Daniel Veditz [:dveditz]]

That doesn't solve the basic problem, which is i18n is parsing string bundle 
.property files as Java property files, where the format is 
<key>=<arbitrary string>. *Any* character, however uncommon, might be a 
legitimate part of a string.

What we really need is a way to tell the property file parser "This is a normal 
property file" vs. "this is a multi-field property file with char(x) as the 
separator", so that whatever changes are required don't affect people counting 
on the original behavior.

Comment 11

[Warren Harris]

Personally, I don't see why we need or want to stick to the java property file 
syntax. The argument for it is simply that it's easy to point people at their 
spec, but why can't we just write up our own? Theirs doesn't deal with white 
space well, nor multiple values. 

The property file parser I came up with is backward compatible except for 
commas, which need to be escaped, e.g. \, and can also allow strings to be 
quoted so that you can have a multi-line property:

myprop = "this is an
example, people can have           
trailing whitespace, \u2345 unicode, commas inside the quotes,
        leading whitespace, etc."

unquoted_prop=this is a single-line prop\, with an embedded comma \
   that extends to the next line (new style with escaped commas)

multi-valued-prop = unquoted-value1,
   value2 with embedded space,
  "quoted value 3 (preferred)",
  value4, value5\,x, "value6,x",
  "c:\Program Files\Netscape"

Comment 12

[Daniel Veditz [:dveditz]]

One reason for sticking with Java property files (in string bundles) is that 
the localization folks already have tools to deal specifically with this 
format. Sure, if you're also volunteering to re-write their tools I'm sure they 
wouldn't mind so much, but wouldn't it be easier to leave string bundles alone 
and make the new format optional?

Comment 13

[Warren Harris]

Not going to make it for beta3 now. nsbeta3-

Comment 14

[Asa Dotzler [:asa]]

reasigning warren bugs to default component owners.

Comment 15

[Doug Turner (:dougt)]

reassign all kandrot xpcom bug.

Comment 16

[Daniel Veditz [:dveditz]]

I'll take this one back if you don't mind.