> "Benjamin Smedberg" <[EMAIL PROTECTED]> wrote in > (no need to crosspost, m.d.embedding is fine for this discussion).
got it. thanks. > The whole "what is a profile and how do I deal with them as an embedder" > question has been blown way out of proportion. A profile is just a directory > to store settings in, and a couple of notifications that tells gecko 1) to > start using the profile and 2) to stop using the profile. Sorry if I did not make myself clear enough. Without proper profile handling, embedding application will definitely CRASH, like mfcembed crahes or activex crashes etc. I'm not sure what proportion is needed there. I think much more than I tried to express :) > The Shutdown() method is pretty clearly documented in the header file. You > need to call it before shutting down XPCOM. If there are bugs about not > shutting down properly (not doing NET_TEARDOWN or whatnot), please file and > fix them. will do. > It shouldn't need to unregister itself, the directory service will release > it during the shutdown process. But it wasn't released. It's pretty simple to see by setting breakpoint in its destructor to make sure couter reached zero or not :) I my case it didn't until I unregistered it manually. > Nobody ever claimed it *could* be used. Of course it can't, because it's > statically linked Right. I know. But there were some posts in this group asking if this possible (without replies) and even more some posts claimed they used xpcom distributed with FireFox (probably it was done agains very early FireFox). But it all does not really matters so far. What matters is why it's FireFox statially linked? Why not to get all components tightly grouped in just one shared object (or dll under Windowz)? Effectively, startup time will be the same but xpcom/gre will be accessible and useful. Look, to distribute my very own application that uses say IE, I don't need to distribute all IE components. It's sufficient to mention that my application requires IE 5.5+ installed. With FireFox, I have to bundle approx 8-10MB and this extra weight bothers me. I'd love to be able to use Firfox distro, especially taking into account how wonderful it is and how fast it is getting popular. I'm sure I'm not alone who is dreaming of this. -dmitry. > "Benjamin Smedberg" <[EMAIL PROTECTED]> wrote in message news:[EMAIL > PROTECTED] > Dmitry Dartz wrote: > > (no need to crosspost, m.d.embedding is fine for this discussion). > > > 1) Old profile management that was available in Mozilla 1.7.x, is not > > available anymore in 1.8.x and by default Makefiles are run > > with MOZ_SINGLE_PROFILE=1 defined, leaving us with those pretty ugly > > profdirserviceprovider_s and profdirserviceprovidersa_s > > The whole "what is a profile and how do I deal with them as an embedder" > question has been blown way out of proportion. A profile is just a directory > to store settings in, and a couple of notifications that tells gecko 1) to > start using the profile and 2) to stop using the profile. > > The Mozilla trunk contains a frozen (dynamically linked) profile API for > embedders (XRE_LockProfile and relatives). On older branches embedders will > have to make do like they always have using profdirserviceprovidersa_s or > custom-rolled code that does basically the same thing. > > > 2) currently profdirserviceprovider is quite a broken stuff and below the > > reasons why I think so: > > > > 2a) It has no interfaces (oh well it has nsISupports but nothing else) and > > all calls to its Register() or Shutdown() methods are > > done against C++ class, not interface. What's about reference counting and > > other really good things offered by XPCOM? By working > > with C++ class you simply bypass them. That's UGLY thing #1. > > That's not ugly, that's just C++. And you can and should be > reference-counting your nsProfileDirServiceProvider* just like any other > thing (don't ever delete it directly). > > > 2c) profdirserviceprovider has no clear way for its shutdown. Although it > > has public Shutdown() method, it's not clear when to call > > it. If I do not call it at all, mainthread clamins that there are remained > > references to when XPCOM (with its glue) is shutted down > > and profdirserviceprovider as you might guess remains in memory (causing > > leaks, of course). If I call it immediately before > > NS_TermEmbedding(), it will trigger assertion "nsNSSComponent relies on > > profile manager to wait for synchronous shutdown of all > > network activity" if network was used. So it looks like current > > profdirserviceprovider does not issue > > PROFILE_CHANGE_NET_TEARDOWN_TOPIC when needed. Needless to say that much > > more nad things happen if Shutdown() called much before > > NS_TermEmbedding(). That's UGLY thing #3. > > The Shutdown() method is pretty clearly documented in the header file. You > need to call it before shutting down XPCOM. If there are bugs about not > shutting down properly (not doing NET_TEARDOWN or whatnot), please file and > fix them. > > > 2d) in Register() method, profdirserviceprovider registers itself in > > NS_DIRECTORY_SERVICE (see directoryService->RegisterProvider), > > but does not unregister itself during Shutdown() and it causes leaks too. > > Leaks are always UGLY things. > > It shouldn't need to unregister itself, the directory service will release > it during the shutdown process. > > > 3) Nothing is said that FireFox 1.5 distro (at least under Windows) can't > > be reused by any embedding application, but that's it > > because there are no components available as standalone dlls, almost all > > are linked statically into firefox.exe. Nothing bad, but > > should be noted somehow on the web. BTW people asked about it on this group > > but no replies. > > Nobody ever claimed it *could* be used. Of course it can't, because it's > statically linked and doesn't expose any useful embedding APIs. XULRunner is > the recommended application framework for all embedders; it exposes real > embedding APIs in C/C++ and Java, and we've spent a significant amount of > time documenting that is is the target for embedded uses of gecko. > > --BDS _______________________________________________ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
