>
> IMHO for the short term, this is going to be a low priority for those
> concerned with shipping Moz 1.0. However, I do think it would
> be neat to have. My question on this (to those that might know):
>
> Is this a pure XPCOM issue or does it require the attention of the
> NSPR group?
Well, my concern was only for making a compiler independent XPCOM. Really
that boils down (if viewed like MSCOM) to having the component manager stuff
accessible, and the memory stuff (since those both are needed when writing
XPCOM components, it only makes sense to have them all a part of the XPCOM
library.)
This would entail writing approx. 7 wrapper functions, which I think I would
be willing to do (since it would take all of 10 minutes.) I'm not certain
how one goes about making a path to Mozilla. Sorry for my ignorance, but if
someone could shed some light on this for me...
Ken
>
> One thing I see awkward with this proposal is that in some
> instances we have NSPR C functions which have #included
> C++ class wrappers as sugar coating. Adding a C wrapper to
> call the C++ wrapper to the NSPR C function is jumping through
> hoops.
>
True, but the main salient goal to was create an XPCOM API. Wherein the user
does not have to worry about how that is implemented, they can just write to
that one API.
IMHO it would be nice if people could not bother with NSPR when writing
XPCOM components. Instead the various functionality and all provided could
be done through components. I have been doing this and it works great,
albeit I have not been doing a lot of intense stuff, so maybe my assumption
is incorrect. Of course XPCOM will use NSPR, but that's fine.
> Unless someone out there REALLY wants to see this interop
> with their favorite compiler and is willing to invest some time, it
> is going to sit for a spell while more urgent issues are addressed.
>
Again, I would be more than willing to make the simple changes for the
component manager and for nsMemory. But I'm not sure how it is done.
Ken
