Doug Turner wrote:
> 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.
Is the embedding requirement articulated somewhere? What capabilities
do we need to expose to embedders?
>> nsIServiceManager needs to be IDLized.
>
> Why should this be have to be in idl to be frozen?
I don't think we want to be freezing non-XPCOM-compliant interfaces (as
are all non-IDL interfaces) as part of our XPCOM core! Why would we
want to? IDL is how we define our interfaces. C++-only stuff in XPCOM
is almost universally a sign that the API is many years old, and in
desperate need of revisiting.
All interfaces should be in IDL when frozen, I think, and I think that's
been the plan of record ever since we started talking about the need to
freeze APIs for 1.0 -- way back in 1999.
>> 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?
You can't mix a debug NS_IMPL_ISUPPORTS_THREADSAFE component with a
non-debug build, because the debug version of
NS_IMPL_ISUPPORTS_THREADSAFE expects to find NS_CurrentThread in
libxpcom. But libxpcom only provides that function -- a two-line
wrapper around PR_CurrentThread, no less! -- if built debug.
I think [EMAIL PROTECTED] and/or [EMAIL PROTECTED] were going to file a
bug.
> Shutting down and threadsafety are concerns, but I do not see them as
> blocking freezing an API set.
I don't see how you can freeze an API without documenting the semantics,
and I don't see how you can document the semantics of something like
XPCOM without talking about threading issues. Just freezing the binary
signature without freezing the semantics gives nothing more than a false
sense of closure. Let's not kid our developers like that.
I also don't understand how you could meaningfully use XPCOM without a
frozen way to shut it down. Lots of components have a need to be shut
down gracefully (prefs, OJI), so I don't think "just leak the XPCOM
universe" is a credible API story.
>> 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.
Well, we sure don't want to freeze the netwerk and i18n dependencies in,
which means that we need to remove them before we can freeze the APIs
they touch (including nsILocalFile, which was on your list, and the
string stuff -- pretty fundamental items).
Mike
