prefs files need to be partitioned / factored

RESOLVED DUPLICATE of bug 224578

Status

()

P3
normal
RESOLVED DUPLICATE of bug 224578
18 years ago
5 years ago

People

(Reporter: jud, Assigned: timeless)

Tracking

({embed, topembed-})

Trunk
embed, topembed-
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [NEEDINFO] [NEEDHELP FOR MAC])

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
Currently an embedding app needs to include all.js, initprefs.js, and 
[OS]pref.js. all.js in particular contains many preferences that don't pertain 
to embedding scenarios. For example, current embedding clients don't need 
mailnews preferences.

Should modules using/needing prefs provide their own prefs file and export it to 
a prefs directory (part of the build process would be to cobble them all 
together at the end)?

Comment 1

18 years ago
yes, we need to move prefs out of modules/libpref/src/init and into their
respective modules. all.js can be broken up into a few files as well.
cc mcafee since he's often interested in this stuff
Status: NEW → ASSIGNED
(Reporter)

Updated

18 years ago
Keywords: embed

Updated

18 years ago
Target Milestone: --- → mozilla1.0
(Reporter)

Comment 2

18 years ago
I'm nominating this for 0.8. Until this is fixed, we'll have to push every pref
under the sun around to embeddors. On top of confusion, each pref yields
overhead in the pref subsystem.
Keywords: mozilla0.8
(Assignee)

Comment 3

18 years ago
i'm working on this, but i'll need to ignore bugmail to finish. and i'm only 
factoring wallet atm.
OS: Windows 2000 → All
Hardware: PC → All
(Reporter)

Comment 4

18 years ago
over to timeless (_THE_ man!). please note the 0.8 nomination.
Assignee: alecf → timeless
Status: ASSIGNED → NEW
(Reporter)

Comment 5

18 years ago
adding jag to cc list.

We haven't really spent time thinking about how to paritition this stuff. But
some toplevel modules I'd seperately package would be I'd make would be.

JS/CAPS
necko
xpfe*
mail/news
i18n
l10n
layout
(Assignee)

Comment 6

18 years ago
ok. time to reduce my bugmail intake.
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.8
from a QA perspective, where would/should these pref files end up? ie, would
they be moved out of default/prefs/ and if so, where? thx!
(Reporter)

Comment 8

18 years ago
I suspect they'll all still wind up in default/prefs, it's just that we'll have
several files rather than just a few. That way, if we're not shipping component
foo, foo's prefs don't have to be shipped either.

Comment 9

18 years ago
Note that loading in the prefs files is a significant proportion of startup time. 
Please try and keep the number and size of the prefs files to a minimum.
(Reporter)

Comment 10

18 years ago
good point. hmmm. we need to somehow consolodate all the files after a full
build, into a single (or fewer) prefs files. Thoughts?

Updated

18 years ago
Blocks: 64846
(Assignee)

Comment 11

18 years ago
Created attachment 23676 [details] [diff] [review]
patch
(Reporter)

Comment 12

18 years ago
excellent! r=valeski. Are we already cobbling .js files together at build time?

Comment 13

18 years ago
Umm...wasn't one of the main goals of 33115 to keep pref loading to a minimum?  
I'd rather this not go in until we work out the consolidation.

(btw, +    $(MAKE_INSTALL) .\init\siderbar.js $(DIST)\bin\defaults\pref -- 
siderbar?)
I think we need some performance numbers. First - for SeaMonkey which reads the
most prefs - is there a performance hit for interpreting a number of smaller
prefs files instead of all.js? I doubt it, but let's find out. Unless there is a
noticable hit we should do this because splitting the files makes it easier for
an embedding app to build a dist. 
(Reporter)

Comment 15

18 years ago
33115 is about removing obsolete prefs entries.

There will certainly be more overhead w/ new file opening/reading/closing going 
on. I've filed http://bugzilla.mozilla.org/show_bug.cgi?id=66877 to address the 
consolodation of prefs files, post build.

This bug is seperate and stands on it's own. Let's move forward w/ a sr= on this 
one and get it in.

Comment 16

18 years ago
sr=alecf

at some point (or as part of this bug) we should be moving the individual .js
files into their respective module's directories

i.e. modules/libpref/src/init/mailnews.js should probably end up in
mailnews/base/prefs/mailnews.js or something similar.
(Reporter)

Comment 17

18 years ago
let's move them out here. timeless, can you make that last revision?

Comment 18

18 years ago
see bug 66877, opening of pref files is expensive.?
Something to think about in terms of speeding up startup.
I applied Timeless' patches and crashed at startup in necko.dll

NS_IMETHODIMP
nsFileIO::GetName(char* *aName)
{
   return mFile->GetPath(aName);
}

(Assignee)

Updated

18 years ago
Depends on: 66877
(Assignee)

Comment 20

18 years ago
current plans for new locations:

all.js
browser.js => xpfe/browser
necko.js => netwerk
sidebar.js => xpfe/components/sidebar
i18n.js => intl
wallet.js => extensions/wallet
mailnews.js => mailnews
editor.js => editor
config.js

ok, the things that are left are [in all.js] of the following types:
images font general signed image clipboard middlemouse css mousewheel profile 
converter silentdownload security advanced prefs nglayout ui imageblocker 
javascript autoupdate

remove [4.x only]:
pref("autoupdate.enabled",              true);
silentdownload.*

belongs in maybe ui.js:
font.*
css.*
middlemouse.*
mousewheel.*

what do people want to do with the others?

as stephend found, my patch can't be committed until bug 66877 is fixed.
(Assignee)

Comment 21

18 years ago
cc module people, please raise your objections here ASAP.  If there are none, 
then I'll make the changes as soon as bug 66877 lands.
Whiteboard: [NEEDINFO]

Comment 22

18 years ago
I see that you've put the cookies prefs into necko.js.  But the cookie module is 
in extensions/cookie and supposedly could be left out of an installation.  But 
in that case the cookie prefs would still be present.
(Reporter)

Comment 23

18 years ago
I think cookies is an edge case. two options:
1. cookies gets it's own cookies.js file
2. we eat the overhead in the *really* off chance that cookies and necko get 
seperated.
(Assignee)

Comment 24

18 years ago
filed bug 67281 for cookies.
Depends on: 67281

Comment 25

18 years ago
<nitpick> Consider renaming necko.js to network.js. Necko was a code 
name and network is more descriptive.</nitpick>

Comment 26

18 years ago
yes, we should do network.js
(Assignee)

Comment 27

18 years ago
yes done, any other things i need to do?  maybe i should work on bug 66877.
(Assignee)

Updated

18 years ago
Blocks: 56243
(Assignee)

Updated

18 years ago
No longer blocks: 56243
(Assignee)

Updated

18 years ago
Summary: prefs files need to be patitioned / factored → prefs files need to be partitioned / factored

Updated

18 years ago
Target Milestone: mozilla0.8 → mozilla0.9

Updated

18 years ago
Keywords: mozilla0.8.1

Updated

18 years ago
Keywords: mozilla0.8
(Assignee)

Comment 28

18 years ago
Created attachment 31653 [details] [diff] [review]
refactor into .jsf files and use rules.m*k to join

Comment 29

18 years ago
Are you still shooting for 0.9 on this?  Do you think that you'll have the two
dependencies fixed in the next day or two?  If so please email
drivers@mozilla.org with a status on you progress. If not please retarget
against a later Milestone. Thanks.
(Assignee)

Comment 30

18 years ago
slipping.  Beard/JJ, I need help on the mac side. When can I get it?
Keywords: mozilla0.8.1
Target Milestone: mozilla0.9 → mozilla0.9.1
(Assignee)

Updated

18 years ago
Whiteboard: [NEEDINFO] → [NEEDINFO] [NEEDHELP FOR MAC]

Comment 31

18 years ago
beard's on vacation, jj soon to be swamped with 0.9.1 release work.
this kind of change would be better early in a milestone, right?

Comment 32

18 years ago
I'm going to unset the target milestone until we get a good
estimate on all the platforms...  this sorta looks like a landing
plan thingy, right?

if we go with separate files we need impact on startup perf numbers.

Updated

18 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Updated

18 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Updated

18 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 33

18 years ago
this one seems to be sliding.. lets try to give it a realistic milestone. 
thanks - chofmann
Target Milestone: mozilla0.9.4 → ---
(Reporter)

Updated

17 years ago
Keywords: topembed

Comment 34

17 years ago
minusing this bug as per edt triage, but we'll take out the minus from topembed-
if the fix is available in the next few weeks.  
Keywords: topembed → topembed-

Comment 35

16 years ago
EDT topembed triage: topembed+ again since this should be a disk footprint win.
 Josh, please reassign if you need help on this one.
Keywords: topembed- → topembed+

Comment 36

16 years ago
*** Bug 158594 has been marked as a duplicate of this bug. ***

Comment 37

16 years ago
topembed minus for the time being per EDT discussion.  

Can we get an estimate of the footprint / performance win?
Keywords: topembed+ → topembed-

Updated

15 years ago
Blocks: 207317

Updated

15 years ago
Blocks: 207315

Updated

15 years ago
No longer blocks: 207315, 207317

Updated

15 years ago
Blocks: 207315

Comment 38

15 years ago
This was accomplished by bug 224578:
modules/libpref/src/init/editor.js -> editor/ui/composer.js
modules/libpref/src/init/mailnews.js -> mailnews/mailnews.js
and more...

*** This bug has been marked as a duplicate of 224578 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Updated

15 years ago
No longer blocks: 207315
You need to log in before you can comment on or make changes to this bug.