Back from Montreal, and I brought a cold with me. Damn.
We found a gorgeous apartment near the Georges-Vanier métro station, and apparently all the paperwork is now in order, so yay. We'll probably move in early June. It's enormous, and beautiful, and I can't wait to move in. I will miss Toronto dearly, but commuting like this sucks in no small way.
My ISP kicks ass. They're going to solve my MTU-DSL problems for me, at some cost to themselves. I am supremely pleased that I can get DSL service from them in Montreal, as well.
- typelibs and the IR are not suitable for comparison. typelibs are an on-disk storage format for interface information, and the IR is a service that permits applications to query for such information. I dimly recall, from our conversation, that mathieu really objects to IDispatch, which is the primary (only?) consumer of COM typelib info in the Microsoft COM world. I agree with his stance: IDispatch is abhorrent, if only because it's stub-based. =)
- It then follows that you can build an IR service, which uses typelibs to store interface data. We do that, basically, in XPCOM, and we call it nsIInterfaceInfoManager. In fact, the implementation of nsIInterfaceInfoManager doesn't even grovel in typelibs directly: it's isolated from the typelib files by the libxpt layer.
A little while back, graydon and I discussed wedging an xptcall-like-thing into ORBit, and blizzard thinks that it wouldn't be too hard to write a CORBA-connecting analogue to XPConnect. We already use the xptcall stuff for proxying between threads, so there's some non-JS marshalling stuff in there to work from. How hard can IIOP be?
Also: Go Leafs.