> 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...
This is a point well taken. We should just make an XPCOM API. This does
include the component manager stuff as well as the memory stuff though.
Basically everything which is in the MSCOM CoApi...
>
> 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...
I agree with this I think. Are you saying you want components to be shared
within the entire system? Like COM on windows? I like this idea a lot. Or
are you suggesting having the ability to get a default implementation of an
interface (without a corresponding class id or contract id?)
>
> 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
>
This is already handled, it is just handled through the one call to
NSGetModule which returns an interface. In my opinion this is perhaps a
superior method since that interface can then be QI'd for additional
functionality, whereas just having more functions exported from the DLLs for
additional functionality is confusingin that it is not just standard COM
stuff...
> 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
>
This is a nice idea in terms of deleting unused items. This is in essence
garbage collection at the file level. The reason why I think the described
method is bad is that it requires these persistent reference counts on the
files to always be correct. If this file gets nuked or corrupted, then it
fails. A different method, borrowing from standard garbage collection, would
be to "mark and sweep" through the component.reg. This would be pretty
simple, you could provide a method in the XPCOM API which would do this. The
algorithm being: run through and find all the dlls which were components
(they provide the NSGetModule or NSGetFactory functions), save this list and
clear all the referenced marks on these items. Then run through your
component.reg and mark every dll that is referenced in the InProc32 key in
"component.reg". Then go through your list again and print or delete or
provide the list of dlls which appear to be out of date, and no longer used.
MSCOM can not provide a similar functionality without searching the entire
machine, since they do not depend on a components dir.
But all I really want is a nice, concise, compiler independent XPCOM API.
And a pony.
Ken
