[tahoe-dev] [tahoe-lafs] #839: Copying directories containing caps from the future

[James A. Donald]

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.