> Many of the things that Tobias brings up are addressed via the > nsICategoryManager. It is a object management system that allows you to > register similar types of objects that can be keyed on some topic.
Ah, thats interesting ... will have a deeper look in that. > So instead of manually munging the contract id yourself, you can go > through an API and request a give type of object that support some topic. > > The interface is here: > > http://lxr.mozilla.org/mozilla/source/xpcom/components/nsICategoryManager.id l#25 > > There are many users of this manager today. Necko uses this > functionality to support different implementations of protocol > listeners. The MailNews team uses this for different implementations of > address book converts based on what type of converted is needed. Take a > look: > > http://lxr.mozilla.org/mozilla/search?string=nsICategoryManager > > Personally, I would rather not have people mundge contract ids by hand. Agreed, its hacky. Actually, I was quite "irritated" about this idiom first .. but I do like the syntactic convenience it gives me at the scripting language level. I don't need to go through any special or custom "factory" but in PyXPCOM e.g. just say components.classes[contract_id].createInstance() as _always_, just with the contract_id of the form blah?param1=10;param2=red Thats not that clean, by the usage is nice. > I am not sure if there is a rule or something about this, but i would > hate to see hundreds of uses be busted if we decide to change how these > strings are handled. You're kidding. Don't do this ;) >They are suppose to be opaque and the category > manager gives parameterization flexibly. > Maybe you need multiple parameters in a contract id as you mentioned. > This is not supported by the category manager. I know that Necko uses > their own contract id parsing to support stream converts. Necko? I'm quite new on Mozilla sources - could you please give me a starting point? How do they _get_ the ContractID, the client provided? > It is a > pretty awesome bit of code. Each contract id has a "from" and a "to" > parameter. The logic create a graph and does a shortest path to > calculate the quickest way to converted one type to another type. I am > not sure that we really need this in xpcom - but certainly, we need to > agree how we are to treat contract id's in general. Absolutely. What about this: having registered a CLSID = 123 for ContractID = "@xyz.com/some-module/foobar;1" a request to instantiate ContractID = "@xyz.com/some-module/foobar;1?param1=small;param2=blue" gets "converted" to an instantiation of component with CLSID = 123 and an automatic call of Init() with one argument: a dictionary of keys-values with unique string keys and values also of type string e.g. Init( dict[('param1', 'small'), ('param2', 'blue')] ) Further, if one registers an "explicit" CLSID for ContractID = "@xyz.com/some-module/foobar;1?param1=small;param2=blue" the above behaviour will be overidden, allowing to choose implementations based on ContractID params, not initialization. The only problem I see is, what happens if a request for an "param extended" ContractID is made, but neither the XPCOM class behind the corresponding CLSID has an Init(dict) method nor is there a registered "explicit" CLSID for "param extended" ContractID. The ComponentManager would have to run-time detect if Init(dict) is available. That could be done when Init(dict) lived in a special Interface the ComponentManager could QI to. > > My 2 cents. > > Doug Turner > Toby.
