I've been tracking down dependencies for the last couple of days and I've noticed that the top two source of dependency problems are StringBundles and Preferences. The XPCOM preference code takes a URI object for it's input. This makes it useless for standalone since building a URI requires necko (which depends on the world). It also appears to be me that at least three different schemes are being used for storing preferences. nsIPref, pref support in XPCOM, prefs as Javascript code. StringBundles have a similar problems they want a URI object for the file and they live in INTL (which depends on everything). One solution to this would be to add two abstract interfaces to XPCOM, one for StringBundles and one for Preferences. For example: GetPreference("URI string", name, value); GetString("URI string", name, value); The preference and string object would then be implemented else where to the abstract interface. These interfaces need to use strings for the URI, not URI objects to eliminate the necko dependency. To generalize this further you could just think of StringBundles as specicalized preference settings and use a common API. Quick scan of the code indicates that these changes would remove around 200 unecessary dependencies.

I'm not sure what you mean by "The XPCOM preference code takes a URI object for it's input." First of all, preferences are not part of xpcom secondly, I don't see any use of URI objects in the preferences api.. by the way, nsIPref is deprecated, and bnesse is supposed to be moving stuff from nsIPref to nsIPrefService/nsIPrefBranch. This isn't really an XPCOM bug, so I'm moving to the "Preferences" component, since it has the biggest dependencies.

Does "pref support in XPCOM" == RDF storage of preferences maybe?

Code like this is needed for both StringBundles and Preferences. The URI introduces a necko dependency. Better to hide the URI on the other side of the interface and pass in strings. static nsresult GetBundle(const char * aPropFileName, nsIStringBundle **aBundle) { NS_ENSURE_ARG_POINTER(aPropFileName); NS_ENSURE_ARG_POINTER(aBundle); // Create a URL for the string resource file // Create a bundle for the localization nsresult rv; nsCOMPtr<nsIIOService> pNetService(do_GetService(kIOServiceCID, &rv)); if (NS_SUCCEEDED(rv)) { nsCOMPtr<nsIURI> uri; rv = pNetService->NewURI(aPropFileName, nsnull, getter_AddRefs(uri)); if (NS_SUCCEEDED(rv)) { // Create bundle nsCOMPtr<nsIStringBundleService> stringService = do_GetService(kStringBundleServiceCID, &rv); if (NS_SUCCEEDED(rv)) { nsXPIDLCString spec; rv = uri->GetSpec(getter_Copies(spec)); if (NS_SUCCEEDED(rv) && spec) { rv = stringService->CreateBundle(spec, aBundle); } } } } return rv; }

the code you pasted is on crack. Where did you find that? I recently ripped some code out of gfx that looked like that. If you look closely, what that code does is to take a string, convert it to a URI object, and then extract the string value of the uri object, and pass that string into nsIStringBundleService. the "spec" it's passing in is a const char*. If you look at nsIStringBundle.idl, you'll see that there is no mention of any necko interfaces. That code could be simplified to: static nsresult GetBundle(const char * aPropFileName, nsIStringBundle **aBundle) { NS_ENSURE_ARG_POINTER(aPropFileName); NS_ENSURE_ARG_POINTER(aBundle); // Create a bundle for the localization nsresult rv; // Create bundle nsCOMPtr<nsIStringBundleService> stringService = do_GetService(kStringBundleServiceCID, &rv); if (NS_SUCCEEDED(rv)) rv = stringService->CreateBundle(aPropFileName, aBundle); return rv; }

oh! I found the code you were referring to in both htmlparser and in layout: http://lxr.mozilla.org/seamonkey/search?string=apropfilename Lets clean that up. I've just filed bug 101562 The rest of this bug will focus on bad preference dependencies.

>The rest of this bug will focus on bad preference dependencies. I have yet to understand how the backend preferences library comes into play with regards to this bug. The only dependency mentioned in the bug is Necko (via URI) and the backend preferences library is not dependent on Necko. What sort of dependency problems are being encountered here?

I have forgotten exactly where I found the preferences problems. I didn't realize it would be hard to locate them. When I wrote this bug I was trying to remove dependencies in two places: htmlparser and gfx htmlparser requires: xpcom string necko util uconv expat layout dom pref nkcache intl widget raptor content It really doesn't need two thirds of these. gfx/gfx windows requires: xpcom string widget util dom locale view uriloader pref timer gfx2 imglib2 mimetype content layout gfx intl uconv unicharutil necko gfx doesn't need most of these. Next I started removing requires and building the directories looking for compile errors. By doing this I believe I found some ancient preferences code in the htmlparser directory. I also found code somewhere (gfx fonts?) that was making it's preferences into a little javascript file and executing it to set them. I can try to find these again. I stopped working on this because I am waiting for http://bugzilla.mozilla.org/show_bug.cgi?id=100612 to get checked in.

Milestone ->Future until someone can tell me what I'm supposed to be fixing here...

topembed- - by triage team (chofmann, cathleen, marcia)

is this bug still relevant?

No.