Kevin Ollivier wrote:
were somehow worked around and removed. And it looks like nsProfileDirServiceProvider may already be fixed for Moz 1.8, so if
It is not frozen in any way, and it *will* break in the future. Profile handling for the new toolkit is much different than the current seamonkey code, and we are planning on embedders using the new toolkit in a consolidated "libxul" form.
> > Is there anywhere I can learn more information about this?
Seamonkey is based around an "xpfe toolkit" built from the xpfe/ directory. The new toolkit rewrites significant parts of this functionality in the toolkit/ directory, and is the basis for the new-style apps such as firefox, thunderbird, NVU, and sunbird. We are planning on building a single consolidated library with a good versioning story called "libxul". The goal is to have embedding customers (such as wxWindows/Epiphany/Eclipse) use only frozen interfaces. In order for this to happen, we need to identify all the non-frozen interfaces you are currently using and find a way to freeze the functionality you need.
One of the major problems with the existing nsProfileDirServiceProvider is the hard-coded application-specific paths (see http://lxr.mozilla.org/mozilla/source/profile/dirserviceprovider/src/nsProfileDirServiceProvider.cpp#291 and following). It is almost certain that we will need to add more file paths to this list as apps change, but if you statically link this file into your embedding app, we can't do that. I don't have a good solution yet, but I can guarantee that things won't stay as they are, it's just not a maintainable solution.
Static NSPR is not a recommended option because of conflicts with DllMain in various cases, and its inability to keep track of thread-local-storage. Note that you *can* munge PATH at runtime on win32, if you use runtime linking instead of dynamic linking.
Do you mean to say that static NSPR can be built already, but isn't working correctly, or that NSPR can't ever be made to work correctly because of the issues above?
It *can* be made to work correctly, but the versioning story it imposes on you is horrendous. What happens when NSPR needs to be updated to fix some bug in gecko?
It is unlikely that the *functionality* of a private interface would disappear, just be moved around in small or big ways. However, you should try to make the mozilla devs aware of which functionality you would *like* to see in frozen interfaces. Many of our internal interfaces are destined to be "deCOMified".
Unfortunately, that's a difficult thing to do as I have no idea about what changes are proposed (i.e. which interfaces are to be removed), nor do I know exactly which features wxMozilla will use in the future. So does this mean I have to vote for each interface that isn't frozen that I'd like to use now or in the future? If so, to be honest I find that to be a rather arbitrary way of making decisions. I have never used an API before where I had to ask the vendor not to remove the functions or interfaces I use in future versions.
You should not consider any non-frozen interface part of our "API." Basically, unless it's marked frozen, you shouldn't touch it. If you are currently using unfrozen APIs (interfaces), let us know why. Any non-frozen interfaces are considered an internal implementation detail of gecko, and can be changed at the needs of the gecko developers. The goal is to work together to identify functionality which needs to be frozen. As you add more functionality to wxWindows, we can freeze more interfaces to suit your needs (assuming that your needs are reasonable, of course, which seems to be the case so far.
If you have to do this, please do this only in your new toolkit so that if it breaks wxMozilla in any serious way I can tell people to stick to the old toolkit (1.x releases?).
The core gecko and embedding interfaces are shared between seamonkey and the new toolkit. We want to fork as little as possible.
--BDS _______________________________________________ mozilla-embedding mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-embedding
