Zooko Wilcox-O'Hearn wrote: > On Monday, 2009-11-23, at 17:51 , James A. Donald wrote: > >> As always, I recommend Microsoft's MIDL/com as a example of general >> purpose, future proof, protocol negotiation for binary complied >> objects. Microsoft has been the technology leader in this field and >> is worthy of imitation. > > Huh, that's interesting. Could you summarize for us the engineering > lessons, or point to some source which does?
Unfortunately this, and the assemblies that are a continuation of it in new technology, is generally described in rather too many alarmingly fat and densely written books, which are probably sitting unread on your bookshelf and threatening to cause it to collapse. So, brutally oversimplifying, and sacrificing accuracy to focus on protocol negotiation, as it was in old days, (it has since become more complex, and at the same time arguably considerably more restrictive, though others might disagree. Maybe I am old fogy who longs for the good old days of assembly) IDL, interface description language describes the object interfaces of of your object class. An IDL file can be compiled into a C++ header and skeleton code file, and into everything needed to make the object accessible from c++ and several scripting languages. Compilation of a single idl file generates the header files for both sides, for the caller and the callee, guaranteeing that they are equivalent, though for various reasons they cannot be identical. The object class receives a long probabilistically globally unique identifier, and a human readable name that need not be unique, and when installed on a computer, it will receive a local name unique to that computer and global to all processes on that computer. Similarly for each of the interfaces, which also get globally unique indentifiers and so forth. To be useful, an object supports a few standard interfaces that almost all objects support, and one or more special interfaces unique to that particular class of object, which do the particular stuff that the class was created for. So any useful object supports at least two interfaces, and often an alarmingly large number of interfaces. When a program, compiled at one time by one person, talks to an object, compiled at another time by another person, it uses the protocol negotiation interface, which all such objects support, to ask if the object supports the interface it wants. What is supposed to happen, though there is no enforcement of this, and probably cannot be enforcement of this, is that if the object and the program both recognize the interface globally unique indentifier, then the interface was on both sides was supposedly compiled from corresponding header files generated by the idl, and are supposedly guaranteed to be able to understand each other correctly. Conversely, if there is a problem, it fails right at the beginning, with the relatively usable error message that it cannot get an interface of the desired type. Typically what happens is you (the program) get a starting object somehow, and then you ask for an interface that you understand, and if you get that interface you use it to ask for another object, rinse and repeat until you get from the object you have to the object you really want and the interface you really want. In C++ this results in an alarmingly large pile of boilerplate resource management code and object lifetime and ownership issues, which issues do not directly correspond to the issues likely to be encountered with capabilities. In script languages, memory management magically takes care of these. If you want to extend an existing type of object, and not break existing code, you add another interface, which often differs from the previous interface by just a single additional function. There is very little overhead in supporting numerous slightly different interfaces, only one of which is likely to be actually used at any run time. Old code will ask for the old interface, and newer code will ask for the newer interface. _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
