- nsIModule - Need to add readonly attribute wstring description; Maybe add dependency info too.

I started to add a name and description attribute to nsIModule, but then I thought maybe this is the wrong thing to do, and instead we should store the name and description in the registry. What do you think, Ray? I'll enclose my diffs.

P.S. The other thing I want to do with this (which really isn't part of this bug) is write and "about:config" handler that enumerates all the modules and lists the name and description in a table. If I made these attributes on nsIModule, then I need a way to enumerate all the module objects, and call their GetName/GetDescription methods. This probably requires them all to be loaded. If we make it a registry field, then all we have to do is enumerate the registry somehow and ask for them.

I believe that, as I have described before, there is a need to have abstract properties which can be associated with each component implementation which registers. Once we have this, reserve one called "component description" or something like that. This solves the need for a component description. I need to complete and check in the modified component manager API which allows these to be enumerated and allows abstract properties to be attached. This does not provide a module description, which is what you probably want for the about box (or perhaps you want both). If memory serves me, the reason we wanted a module description was to put in information about packaging details such as build identification, date, and time. Perhaps much of this information is automatically generated at build time. We currently lack a way of enumerating the modules registered in the registry. We need this to access module descriptions whether or not they are stored in the registry (unless we want to register the same build info with each component redundantly as an abstract property, which could bloat the registry worse than anything I have ever proposed, but may be the simpler way). We also need a way to make this description available. If this is a method on the module, the autoregistration can easily ask for it and enter it in the registry if we decide to cache it there. I think this is a good idea. We just need a call to ask the registry to enumerate modules, and get the description from that.

Ok, this now depends on the new component manager stuff, bug 46768.

Not holding PR3 for this; marking nsbeta3-.

reasigning warren bugs to default component owners.

reassign all kandrot xpcom bug.

do we even need this? I mean, looking at the patch, alot of the descriptions are empty. Furthermore a nsIModule has a 1-many relationship with components. The description belongs there if anywhere. The nsIClassInfo already has this parameter. Markin INVALID.