100692 - Need component manager API to tell if a service has been instantiated

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Simon Fraser [no longer active]]

In bug 67409, I have a need to call some mail APIs, but only if the mail DLLs are 
already loaded. I don't want my GetService call to cause those DLLs to load.

So, I need an API on the component/service manager that tells me if the service 
with a given CID/contract ID is in existence.

Comment 1

[Suresh Duddi (gone)]

Many times when this need cameup, it was mostly solved with observers and
categories. Those proved to be more right solutions.

I am hoping that you would evaluate those options and come to conclusion on
whether this is required.

Comment 2

[Doug Turner (:dougt)]

I agree with dp.  Maybe mail should just fire a notification that it is present
on startup.  If your component needs to do something based on this, it can be a
listener to topic.

Comment 3

[Simon Fraser [no longer active]]

Why is it wrong to ask the service manager "Does service X exist already"? It 
seems like this would be essential to any performant app that wants to avoid 
loading DLLs eagerly. Having to set up observers and categories seems like an 
obtuse way to solve the problem. The implementation for "does the service exist" 
also looks very easy (just a hash lookup).

Comment 4

[Doug Turner (:dougt)]

with my suggestion, you might run into a problem if you need to check at startup
and your component was loaded after mailnews started up.  In this case, you
would never heard a notification!  

reopening.

Comment 5

[Suresh Duddi (gone)]

Simon, I totally think it is a valid question to ask. The issue I have is people
would have asked this question if it existed in all the wrong places.

What information can be derived from a service existing or not ?

- like you are trying to infer a dll is loaded or not. That assumes that
particular service exists in that particular dll and that no other service
hosted by the dll has been created earlier to this. That is too much of an
assumption.

- I think it would be valuble but I just dont know where yet.
Shaver ?

Comment 6

[Simon Fraser [no longer active]]

> - like you are trying to infer a dll is loaded or not. That assumes that
particular service exists in that particular dll and that no other service
hosted by the dll has been created earlier to this. That is too much of an
assumption.

Good point, but I'm not sure it really matters. I guess I need to know "does a 
GetService() for this service have any chance of loading DLLs that weren't 
loading before". i.e. I need to be able to make a prediction about whether it 
will be cheap or not. It doesn't matter if the DLL is already loaded for some 
other service; I'll just be overly pessimistic about how expensive getting the 
service might be.

Comment 7

[Mike Shaver (:shaver emeritus)]

As people start to integrate SOAP and other wild-and-wacky component types, the
ability to determine whether we've already paid the cost of loading a given
factory is probably going to be valuable.

I thought that I'd suggest amending nsIComponentManager::getFactory to take an
additional boolean parameter.  If true, the component manager should attempt to
load components in order to resolve the factory request.  If false, it
shouldn't.  Of course, the problem with _that_ is that there's no way to go from
an nsIFactory to a service, only to an instance.  Shame that our
nsISingletonFactory/nsIModule::getClassObject stuff was stillborn.

smfr could use this mechanism to solve his "is mail loaded?" conundrum, though I
really think that, as we discussed on IRC, his _specific_ problem with respect
to network connection state may be best solved with some sort of netwerk
connection enumerator.  I don't like the several levels of assumption that are
involved in the leap from "mail has been loaded" to "there may be network
connections in this state".
(I also think that having to hand-write a bunch of observer/category scaffolding
is too burdensome for this sort of problem.  Maybe we need a simple
nsIApplicationState service that can be used as a bulletin board for different
components to tell the world about their state.  But that's for another bug, and
another day.)
Marking this as blocking the "nsIComponentManager changes" bug until we
determine if this may result in nsIComponentManager API changes.  And I'm taking
the QAContact from scc, because he has enough on his mind right now. =)

Comment 8

[Suresh Duddi (gone)]

GetFactory(.., PRBool dontCreate);

That sounds good to me. ServiceManager can still use it - instead of calling
createinstance directly, it would have to getfactory() and then create instance
off it and letgo of the factory.

But now, that is 2 API changes we are talking about - ComponentManager and
ServiceManager.

Comment 9

[Suresh Duddi (gone)]

Attachment: Temporary patch for branch. Adding function NS_GetService()

Comment 10

[Suresh Duddi (gone)]

To help fixing but 67409 in the branch right away, the least risky way seems to
be adding this api. When we fix it the right way in the brach, we can remove
this function and migrate the caller to the new way.

Need r=/sr=

Comment 11

[Simon Fraser [no longer active]]

+nsresult
+nsComponentManagerImpl::fetchService(const char *aContractID, const nsIID& aIID, 
nsISupports** result)

Uppercase the 'f' and you've got r=sfraser

Comment 12

[Doug Turner (:dougt)]

Comment on attachment 50626 [details] [diff] [review]
Temporary patch for branch. Adding function NS_GetService()

looks okay.  I am not sure about using a lower case 'f'.

Comment 13

[Suresh Duddi (gone)]

sfraser: done.

Comment 14

[Scott MacGregor]

Comment on attachment 50626 [details] [diff] [review]
Temporary patch for branch. Adding function NS_GetService()

sr=mscott

Comment 15

[Suresh Duddi (gone)]

NS_GetService() patch checked into trunk.

Comment 16

[Doug Turner (:dougt)]

The service manager has a method to do this.  See:

http://lxr.mozilla.org/seamonkey/source/xpcom/components/nsIServiceManager.idl#78