svn commit: lorikeet r549 - in trunk/white-papers/dcom: .

[jelmer at samba.org]

Author: jelmer
Date: 2006-05-25 19:07:28 +0000 (Thu, 25 May 2006)
New Revision: 549

WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=lorikeet&rev=549

Log:
Update DCOM paper to reflect some new insights - DCOM should be 
based on Mono and its' COM support and utilize Samba's DCE/RPC + ORPC code 
instead of having our own COM implementation in Samba, which is too much 
work to implement and harder to code (C).

Modified:
   trunk/white-papers/dcom/dcom.tex


Changeset:
Modified: trunk/white-papers/dcom/dcom.tex
===================================================================
--- trunk/white-papers/dcom/dcom.tex	2006-05-10 20:05:58 UTC (rev 548)
+++ trunk/white-papers/dcom/dcom.tex	2006-05-25 19:07:28 UTC (rev 549)
@@ -308,8 +308,10 @@
 DCOM and COM together, ignoring the concept of proxy classes. This attempt failed because it 
 made matters very complicated. 
 
-The final attempt seperates the COM and DCOM implementations (somewhat similar to Windows), making the code simpler.
+\subsection{First try}
 
+The second attempt seperated the COM and DCOM implementations (somewhat similar to Windows), making the code simpler.
+
 \begin{itemize}
 \item $lib/com$ contains a very simple (but sufficient) COM implementation. 
 \item $lib/com/interfaces$ contains pidl generated structure files for the COM interfaces
@@ -317,7 +319,7 @@
 \item $lib/dcom/proxies$ contains the pidl-generated proxy files
 \end{itemize}
 
-\subsection{COM implementation}
+\subsubsection{COM implementation}
 
 Since Samba is written in C, which is not object-oriented, COM calls in Samba 
 are made using function pointers in structs. This works 
@@ -457,62 +459,34 @@
 TODO: 
 	Split out NDR-related and other stuff in ndr\_*.h
 \end{verbatim}
-	
-\section{Future integration}
 
-\subsection{OpenPegasus: WMI}
+\subsection{Integration in Mono}
 
-WMI (Windows Management Instrumentation) is Microsofts implementation of 
-the Web-Based Enterprise Management (WBEM) standard from the 
-Distributed Management Task Force (DMTF). 
+COM contains a lot of classes, making it very time-intensive (if not 
+impossible) to implement. Since it is object-oriented by nature, it is 
+also much easier to implement in an object oriented language, rather than 
+C. 
 
-One of the parts of WBEM is the Common Information Model (CIM) \cite{CIM}, 
-which is a data model for various types of management information.
-
-WMI is built on top of (D)COM\cite{COMWMI}; it looks like implementing WMI 
-will be possible by implementing a thin layer of (D)COM classes. For the 
-client-side, this should be sufficient. For the server side, 
-using the OpenPegasus \cite{OpenPegasus} backend might be an option, 
-though this would probably require a lot of integration work.
-
-An interesting option would be to create Python bindings for DCOM 
-on Linux so it can be used with WMI, with an API similar to that 
-of the Python-WMI\cite{PythonWMI} project.
-
-\subsection{Mono}
-
 DCOM is currently mostly a legacy technology, with Microsoft 
 focussing on the .NET framework. The .NET framework in 
-the Windows world has compatibility for COM built in. Rather then 
+the Windows world has compatibility for COM built in. Rather than 
 a hard-coded standard for remoting, the .NET framework supports 
 various backends, DCOM being one of them.\cite{DotNETRemotingIntro}
 
 Mono\footnote{http://www.mono-project.com/} is an open source project 
-that aims to implement Microsoft's .NET framework. 
+that aims to implement Microsoft's .NET framework. Work is currently in 
+progress to implement COM support for Mono.
 
-It should be relatively easy to add support for DCOM, perhaps somewhat 
-similar to Remoting.Corba\footnote{http://remoting-corba.sourceforge.net/}.
+It should be relatively easy to add support for DCOM 
+once the COM support is done, perhaps somewhat 
+similar to Remoting.Corba\footnote{http://remoting-corba.sourceforge.net/}, 
+based on Samba's DCE/RPC code.
 
-It is likely, however, that Samba's DCOM implementation is not necessary for 
-this, only it's DCE/RPC implementation and ORPC extensions (see again 
-\ref{relations}).
-
-\subsection{Wine}
-(Ideas)
-\begin{itemize}
-\item ability to disable either rpcss or Samba's epmapper support
-\item use epmapper and rot pipe internally as well as externally
-\item support for ncacn\_unix\_ds: in wine or ncalrpc: in the same fashion 
-  as Samba?
-\item Proposal: Keep all the object management stuff in Samba, but allow
-  Wine (thru the ROT interface) to add new objects. This allows the Wine folks 
-  to use the Samba infrastructure for now, while giving them the opportunity 
-  to move to a Wine-specific implementation of this stuff later on, if necessary.
-\end{itemize}
-
-\subsection{Mozilla (ActiveX)}
-There is a plugin for Windows only at the moment, available in Mozilla CVS \footnote{http://www.iol.ie/~locka/mozilla/plugin.htm}. Maybe extend to support *nix ?
-
+This makes the scope of the problem a lot smaller --- it means no longer 
+being required to reimplement COM in Samba. The only thing necessary for 
+this, is the DCE/RPC implementation and ORPC extensions from Samba and 
+some way to generate Proxy/Stub objects in Mono (see \ref{relations}).
+	
 \bibliography{dcom}
 
 \end{document}