Hello,
> For example, the nsMemory class provides quite a few useful static methods.
> We would add wrapper functions for each static method which would then be
> declared extern "C" and would just call the nsMemory methods.
Ken, this wouldn't make much sense in the way you describe it. At least it is
too late to redesign things. Beside, most of the things are in NSPR which *is*
with C API. What I would suggest is:
1. Reduce functionality of XPCOM.DLL to ONLY maintain components and component
registry - equal to CoCreateInstance, CoInitialize etc...
2. Design guidelines for global component installation. For example Netscape
develop nsIWidget interface, and even implement it :) But other company might
decide they could do it better, so user can use the other implementation, but
it does not make much sense to install plenty of DLL's implementing same
functionality for different applications. It is all a matter of design.
Someone should design/implement let say nsIPop3Protocol, then this protocol is
installed for a systemwide usage. Later, let say a browser, can use this
implementation to retrieve mail, and in fact implement somthing like pop3://
protocol to handle email. This is just a rough example...
3. Define guidelines about functions that any XPCOM compatible DLL should
export. Equal to DllRegisterServer, DllUnregisterServer, DllGetClassObject.
This would allow to an independant vendor to develop/distribute a DLL, that
would be installed in XPCOM directory and will become available for use
4. Instead of supporting DLL counters based on application usage, cound class
ID's implemented in this DLL... if someone install another CID for, then
previous DLL counter will be decreased, and once this DLL serve nothing more,
it is moved to specific folder, something like "SCHEDULED_FOR_DELETE" or
"NOT_USED_ANYMORE". Example: if WIDGET.DLL serves CLSID_Window and
CLSID_Button, then its counter is 2. If later someone install another DLL and
tells XPCOM that CLSID_Window is implemented there, then WIDGET.DLL counter
become 1. Application instalation could/should check if required classes are
already implemented, then decide whether to install them or not.. if another
DLL is installed, that implements both CLSID_Window and CLSID_Button, then
WIDGET.DLL can be disposed
I would definetly love XPCOM if it works as described above :)
--
--
Regards,
Waleri
