> I very much agree with your target goals: initialization; component 
> registration, instantiation, loading and unloading; and shutdown.  I 
> just don't think that things like nsAgg.h need to be part of that, and I 
> think that there's a whole lot of work to do just around getting those 
> "few" pieces right, so we don't want to borrow trouble.


Great!  I think that a minimal set is all we need to fill the embedding 
requirement.  If we don't have to freeze C++ stuff, all the better.


> Which?  nsIComponentManager has stuff that needs to be taken out of it 
> (like most of the RegisterComponent calls, which imply a shared-library 
> component loader); it has some [noscript] methods that need to be made 
> scriptable; it needs to stop using nsIEnumerator in its interfaces; 
> freeLibraries needs to take a |when| parameter (and probably pass it 
> along to nsIModule::canUnload).  


Okay. I will start filling bugs and find people to fix these problem (or 
I will fix them).

> nsIServiceManager needs to be IDLized. 


Why should this be have to be in idl to be frozen?

>  Even the NS_IMPL_ISUPPORTS stuff needs to be changed, so that we don't 
> rely on a debug-only NS_CurrentThread.


could you elaborate?

 
> Yes, we need to get the interfaces into the final form, so that 
> consumers can start writing to the new, frozen APIs.  But there are more 
> issues than just the signatures of methods and layout of XPCOM 
> interfaces to nail down, like threading: what components and methods are 
> re-entrant?  Which are threadsafe?  Can you call shutdown on a different 
> thread than you ran the initialization on?  Can you release a service on 
> a different thread than the one you grabbed it on?


Shutting down and threadsafety are concerns, but I do not see them as 
blocking freezing an API set.

 
> What about the STANDALONE build?  What about dependencies on netwerk?


it is sick.  did you see alecf's posting in the embedding newsgroup? 
Bug again, I do not see how this can block freezing a set of interfaces.

 
> Now that nsAString is a typelib-supported type, we need to freeze and 
> document its binary layout.


Part of a string bug assign to scc.



Reply via email to