Doug Turner wrote:
> Mike Shaver wrote:
>
>> Doug Turner wrote:
>>
>>> I am pushing to freeze the core parts of XPCOM. The reason is
>>> simple, changes are busting users of xpcom clients. There needs to
>>> be a definitive list of the frozen API which embedders and xpcom
>>> developers can reference.
>>
>> I think it's premature to be freezing large pieces of XPCOM. We
>> _know_ that we're going to be making some substantial changes to
>> things like the nsIComponentManager/nsIServiceManager relationship,
>> and we need to do some hard thinking about what our interfaces need to
>> look like so as to support things like multiple XPCOM registries.
>
> I never said we are going to freeze large pieces. I said 'core parts of
> xpcom'. We need to be able to have a set of frozen interfaces that will
> allow initialiation, basic component handling, and shutdown.
When you say "interfaces", are you talking about XPCOM/XPIDL interfaces?
You listed header files in your original list, which made me worry a
little; with the exception of a very small number of bootstrapping
functions (like NS_InitXPCOM), I think we should _only_ be freezing
interfaces defined in IDL. People who care about cross-build binary
compatibility won't be able to use all our pretty C++ helper functions,
but I think that's better than trying to nail down permanent semantics
for them. (I worry about things like the netwerk URI-parser situation,
where I believe you _have_ to use a C++ helper to correctly access a
parser for a given URL type. What of non-C++ languages? What of
plugins that can't link against Mozilla libraries?)
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.
> Most of these interfaces are already 'defacto' frozen.
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). nsIServiceManager needs to be IDLized.
Even the NS_IMPL_ISUPPORTS stuff needs to be changed, so that we don't
rely on a debug-only NS_CurrentThread.
There's lots of work to do here before we can freeze, IMO.
> I want to add some
> assurance to clients that there is a set of core xpcom apis which are
> frozen.
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?
What about the STANDALONE build? What about dependencies on netwerk?
Now that nsAString is a typelib-supported type, we need to freeze and
document its binary layout.
(_Lots_ of work to do before we finish freezing.)
> We have many customers of XPCOM which have no idea which API's to use.
> They break between builds. This is unacceptable.
Well, there's a reason we haven't stamped it as 1.0 yet. We have a
small set of frozen-and-supported APIs, thanks to Jud's hard work, and
people who don't stick to those APIs are currently asking for trouble.
(Our plugin samples are a bad case of developer entrapment, because the
samples show use of non-frozen APIs, but that's a separate problem and
one that Patrick is working hard on.)
> Furthermore, we can
> not freeze our embedding APIs until there is enough core xpcom.
Right, as with plugins.
> What is the problem with the current
> nsIComponentManager/nsIServiceManager relationship? If this is related
> to merging the two, see 96457.
That merger was meant to be an example, but I seem to have forgot the
"for example". It's also not clear how nsIComponentManager::findFactory
is related to the service manager, but that may be simple to resolve.
> It has been suggested that we could also provide a static libary of
> these functions, ect. If needed xpcom clients (eg plugins) could
> directly link to this library without having to pull in all of xpcom.
> Does this sound like a good plan to you?
Sounds pretty good, yeah. Not requiring people to link against
libxpcom.so in order to be a component is _mandatory_, IMO.
Mike
