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. 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.idl#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. 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. 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. 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. My 2 cents. Doug Turner Mark Hammond wrote: > Tobias Oberstein wrote: > >> With parameters in ContractIDs I mean something like this: >> >> "@xyz.com/some-module/foobar;1?param1=small;param2=blue" >> >> where param1 and param2 can take values of some predefined >> >> sets {'small', 'medium', 'big'} and {'red', 'blue'}. > > > It is not clear what you are asking. contract IDs are unique(ish) > strings. For every known contract ID, there is a class ID, which > uniquely identifies a component, as implemented in some source file > (generally .c/cpp or .js) > > So all you need to do is register an xpcom component with the contract > ID "@xyz.com/some-module/foobar;1?param1=small;param2=blue" > >> Further, it should be acceptable that a client may _not_ resort >> parameters like this: >> >> "@xyz.com/some-module/foobar;1?param2=blue;param1=small" > > > No problem - that is a different, unknown string. > >> 1. Are there established patterns of design to realize such stuff? >> a) .. where there is one implementing class and the ContractID >> parameters are used to initialize some member vars of the >> implementing class > > > The contract ID generally exists in a source file. One source file > could implement many components. > >> b) .. where there are multiple implementing classes and the >> parameters are used to choose the appropriate implementation > > > It is only ever done (as far as I know) using different contract IDs. > Not params as such, but call it that if you like :) > > >> i) .. and the different implementations are manually programmed >> implementation classes > > > Not sure what you are asking. > >> >> ii) .. and the different implementations are compile time >> generated via C++ template classes > > > I can't recall seeing any such samples, and according to the C++ style > guide (see mozilla.org) that would not be portable. Could be done > pretty simply though. > >> 2. If there are different ways of doing it, what questions should >> I ask myself in choosing my way? > > > Should you be using javascript or Python? Or using simple C++ inheritance? > > [snipped way more code than I have time to play with] > > Mark. >
