Closed
Bug 43393
Opened 24 years ago
Closed 15 years ago
implement xap files
Categories
(Core :: XPCOM, defect, P3)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: warrensomebody, Unassigned)
Details
(Keywords: arch, Whiteboard: [nsbeta3-])
(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.
Reporter | ||
Comment 1•24 years ago
|
||
See bug 36031 "Mozilla components cohesion issues" -- why I think explicitly stating component dependencies would be a good thing.
Reporter | ||
Comment 2•24 years ago
|
||
Cc'ing David.
Reporter | ||
Updated•24 years ago
|
Target Milestone: --- → M20
Reporter | ||
Comment 3•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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 :)
Keywords: nsbeta3
Comment 6•24 years ago
|
||
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•24 years ago
|
||
mozilla is accepting patches.
Reporter | ||
Comment 8•24 years ago
|
||
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•24 years ago
|
||
er, seperation chars....how about | (pipe) or ! (exclamation mark)?
Comment 10•24 years ago
|
||
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.
Reporter | ||
Comment 11•24 years ago
|
||
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•24 years ago
|
||
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?
Reporter | ||
Comment 13•24 years ago
|
||
Not going to make it for beta3 now. nsbeta3-
Whiteboard: [nsbeta3-]
Updated•24 years ago
|
QA Contact: leger → kandrot
Comment 14•23 years ago
|
||
reasigning warren bugs to default component owners.
Assignee: warren → kandrot
QA Contact: kandrot → scc
Updated•22 years ago
|
Status: NEW → ASSIGNED
Updated•18 years ago
|
Assignee: dveditz → nobody
Status: ASSIGNED → NEW
QA Contact: scc → xpcom
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•