hi, I am really new to Mozilla and the XPcom stuff so I hope people will not be too unhappy about the stupid factual errors in this mail. I am currently working on some stupid project of mine: http://nautilus.eazel.com/mango/book1.html (outdated spec. look in gnome' cvs module mango for a more up-to-date version of the spec) While doing all this I realized I needed some runtime knowledge about the inheritance tree of the interfaces of my CORBa objects. In CORBA land, the Interface Repository (see CORBA spec) was designed exactly for this. The only problem is that there are no IRs out there in the open which are able to load the data about an interface without any manual intervention of the developer. So, I started using the ORBit' half finished IR. My current approach is to parse at runtime the IDL files installed on the system by the Gnome libraries and to feed the data to the IR... This is completely broken in a number of ways. The two main problems are that at runtime, you know nothing about the necessary flags to use to compile the IDL and you will always load all the data in the IR even if it does not need it. So, I need typelibs :) Here are the main differences betwwen Gnome' use of CORBA and mozilla' use of XPCom (as I see it) 1) activation/implementation identification. Gnome has something called OAF which is similar in scope to the CORBA Trader service: it allows us to instantiate CORBA components given a set of properties it is supposed to support. It is pretty powerfull and uses internally UUIDs to indentify implementations. Mozilla has no such thing as OAF (it uses a mechanism similar to the windows' categories) and it can at best associate a ClassID to a user' readable string. The ClassID is a UUID which has more or less the same role as in OAF to uniquely identity implementations. 2) interface definition Gnome uses pure IDL and repo_ids to uniquely identify interfaces. Mozilla uses interface UUIDs to uniquely identify interfaces and hardcodes those in the IDL files using an extension to the native CORBA IDL. 1) is not really relevant to the folowing discussion but I included it because understanding activation in mozilla is pretty important for me. (please, tell me if I was wrong) 2) is probably the reason why typelibs use the iids to in their InterfaceDirectoryEntry. If I were to reuse typelibs, I need to replace the iids used natively in typelibs by something else because there is no way Gnome is going to abandon the pure CORBA IDL to store the interfaces' iids (I could do it but I doubt I would be able to sell it to any other Gnome developper :) There are 2 solutions to this problem: - use the iid field to store a pointer in the data heap of the typelib file to a string of the repo_id. I hate this because it would mean: 1) hacking typelib code (forking) and it would dimish the performance of the typelib file format. - have some magic injective function which can generate on-the-fly a 128 bit value from a repo_id so that we can store uuids in the typelibs and get the uuid for a given repo_id later. Now, there are the issues which I would like to understand: - Can the mozilla code resolve missing interfaces from a typelib file at runtime with little performance loss ? If so, where is the code ? - How close is the typelib stuff from being able to store full CORBA-IDL compliant stuff ? - Can the mozilla code cache the data about the typelibs (ie: direct quick association between iid and typelib file ?). I think so: I guess that the mozilla registry file contains such data and it is built each time regxpcom is run, no ? I understand this message is a little long but I would really like to be able to reuse typelibs someday tp workaround the ugly hack I am currently using... So, have I said anything blatantly wrong about Mozilla's XPCom and its typelibs ? I would love if anyone could answer to any of the questions left at the end and/or confirm I have not said anything too stupid. regards, Mathieu -- Mathieu Lacage <[EMAIL PROTECTED]>
