extensions/mono/README

   1 A CURSORY AND LIKELY MISLEADING GUIDE TO MONOCONNECT
   2
   3 General Architecture
   4 --------------------
   5
   6 The goal of this code is to provide a two-way bridge between the
   7 CLR/.NET/Mono/C#/etc. world and XPCOM.
   8
   9 We want:
  10  - Natural C#/etc. syntax for consumers.
  11  - Acceptable performance (wrapper space and call speed)
  12  - "Correctness" (maintenance of object identity, reference management).
  13  - Dynamic, lazy generation of stubs and interfaces from interface-info.
  14
  15 We do not want:
  16  - People distributing generated stubs.
  17
  18 To that end, we register for TypeResolve and AssemblyResolve events on
  19 our AppDomain (components.cs, RegisterAppDomainHooks).  When user code
  20 references an interface or stub-proxy that we have not yet generated
  21 (and is not special-cased, like nsISupports), our TypeResolve hook
  22 triggers the generation of an appropriate class.
  23
  24 The generation of proxy classes happens in generate-proxy.cs, where we
  25 employ the many wonders of System.Reflection.Emit to create a proxy
  26 for the indicated interface.  The proxy class for a given interface
  27 will have specialized marshalling code emitted for the specific
  28 interface parameters and index.  There is currently virtually no code
  29 shared between proxy methods, which is something that we should remedy
  30 in the future: a rough census of Mozilla interfaces (circa 1.6)
  31 indicates that generating a static helper method or delegate per
  32 unique method signature would give us significant savings.
  33
  34 typeinfo.cs has a bunch of infrastructure for inspecting interface
  35 info from the IIM.  I am not particularly proud of any of that
  36 infrastructure, but it does get the job done at present.  Lots of it
  37 is likely not even used today, since it largely predates actual proxy
  38 generation.  xptinvoke.cs is along the same lines.
  39
  40 (typeinfo.cpp exists mainly because we need C-linkage entry points for
  41 P/Invoke, and secondarily because I wanted to reduce mono<->C thunking
  42 as much as was easy.)
  43
  44 wrapped-clr.cs is where the CLR-implementing-XPCOM-interfaces code
  45 should go.  Today, it basically...who am I kidding?  You can see the
  46 source, it clearly does almost nothing.  I have fantasies about
  47 patching the C++ vtable with JITted delegate pointers.
  48
  49 There's one piece missing to this puzzle (other than all the other
  50 pieces): we need to generate metadata-only interface assemblies for
  51 people to compile C# against, because our TypeResolve/AssemblyResolve
  52 tricks are not enough to get us wired into the compiler.
  53 tools/generate-interfaces.cs is that tool, mostly.
  54
  55 Other things that are missing:
  56 - AString support
  57 - Exceptions
  58 - figuring out a good way to map casting to QI
  59 - a component loader