[prev in list] [next in list] [prev in thread] [next in thread] 

List:       samba-cvs
Subject:    svn commit: lorikeet r236 - in trunk/white-papers/dcom: .
From:       jelmer () samba ! org
Date:       2005-02-28 22:11:15
Message-ID: 20050228221115.89387162B6F () lists ! samba ! org
[Download RAW message or body]

Author: jelmer
Date: 2005-02-28 22:11:15 +0000 (Mon, 28 Feb 2005)
New Revision: 236

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

Log:
Add diagram explaining the relation between DCE/RPC, NDR, COM, DCOM, ORPC and 
.NET Remoting
Add diagram with pidls internal structure and logic

Added:
   trunk/white-papers/dcom/pidl_structure.dia
   trunk/white-papers/dcom/relations.dia
Modified:
   trunk/white-papers/dcom/Makefile
   trunk/white-papers/dcom/dcom.tex


Changeset:
Modified: trunk/white-papers/dcom/Makefile
===================================================================
--- trunk/white-papers/dcom/Makefile	2005-02-28 14:28:41 UTC (rev 235)
+++ trunk/white-papers/dcom/Makefile	2005-02-28 22:11:15 UTC (rev 236)
@@ -3,7 +3,7 @@
 BIBTEX = bibtex
 DIA = dia
 
-IMAGES = interface-implementation.mps object-exporter.mps call-local.mps \
call-remote.mps +IMAGES = $(patsubst %.dia,%.mps,$(wildcard *.dia))
 
 all: dcom.pdf
 

Modified: trunk/white-papers/dcom/dcom.tex
===================================================================
--- trunk/white-papers/dcom/dcom.tex	2005-02-28 14:28:41 UTC (rev 235)
+++ trunk/white-papers/dcom/dcom.tex	2005-02-28 22:11:15 UTC (rev 236)
@@ -67,7 +67,7 @@
 
 \begin{figure}
 \includegraphics[scale=.40]{interface-implementation}
-\caption{An example of DCOM's distinction between interface and implementation}
+\caption{An example of COM's distinction between interface and implementation}
 \end{figure}
 
 \subsection{Interfaces}
@@ -148,7 +148,7 @@
 \begin{itemize}
 \item Binding directly to the ``Class Object''. This can be used to do either a \
``static'' call or to call $CreateInstance$ (if the class object supports the \
$IClassFactory$ interface) to return a new class instance  \item Create an instance \
based on the CLSID. Windows looks up the CLSID in the registry, finds the associated \
                DLL or EXE and loads it. ($CoGetInstanceFromFile() $)
-\item From Persistent State Object %FIXME
+\item From Persistent State Object. This creates an instance from a $IStorage$ \
pointer  \end{itemize}
 
 Objects returned by other calls all use one of the three ways described above in
@@ -180,9 +180,16 @@
 
 Distributed COM is nothing more then a 'hack' to make standard COM work 
 remotely. It was added later as a way to allow the distribution of COM objects 
-over multiple computers. It is basically the glue between DCE/RPC \
                \cite{opengroupdce} and 
-COM. 
+over multiple computers. It is basically the glue between DCE/RPC \
\cite{opengroupdce} and COM, as drawn in \ref{relations}  
+\begin{figure}
+\caption{The relations between COM, DCOM and DCE/RPC}
+{\center
+\includegraphics[scale=.50]{relations}
+}
+\label{relations}
+\end{figure}
+
 DCOM is not as closed as one might think; there are several documents available 
 from Microsoft explaining the wire format \cite{UnderstandDCOM,DCOMarch}. There has \
even   been an Internet draft on DCOM \cite{DCOMSpec}.
@@ -211,10 +218,8 @@
 Every object lives in a certain context, known to Windows programmers as 
 an {\em apartment}. Calls crossing apartment boundaries need marshalling.
 Usually the term apartment maps to a thread. Apartments are identified 
-remotely by Object Exporter IDs (OXIDs)\footnote{I think these are just thread IDs, \
                which are 
-unique to the system on Windows.}.
-% For samba, let's use getpid() for OXIDs or some function for thread id's
-% from pthreads
+remotely by Object Exporter IDs (OXIDs)
+unique to the system on Windows.
 
 \begin{figure}
 \includegraphics[scale=.50]{object-exporter}
@@ -369,6 +374,16 @@
 extension do not require large amounts of changes in 
 the pidl code nor do they increase the complexity of the pidl code.
 
+\newpage
+\oddsidemargin=0em
+\begin{figure}
+\caption{The data flow inside pidl}
+\includegraphics[scale=.40]{pidl_structure}
+\end{figure}
+\newpage
+
+
+
 The additional pidl module, $com_header.pm$, generates C header files that contain 
 structs with function pointers for each object interface. They also generate wrapper \
macros for  easier use of the interfaces. 
@@ -400,7 +415,7 @@
 struct IUnknown {
 	struct com_context *ctx;
 	struct IUnknown_vtable *vtable;
-	void *object_data;
+	void *object_data;x1x
 };
 
 #define IUnknown_QueryInterface(i,m,p1,p2) \
(i->vtable->QueryInterface(i->object_data, m, p1, p2)) @@ -460,6 +475,10 @@
 It should be relatively easy to add support for DCOM, perhaps somewhat 
 similar to Remoting.Corba\footnote{http://remoting-corba.sourceforge.net/}.
 
+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}

Added: trunk/white-papers/dcom/pidl_structure.dia
===================================================================
(Binary files differ)


Property changes on: trunk/white-papers/dcom/pidl_structure.dia
___________________________________________________________________
Name: svn:mime-type
   + application/octet-stream

Added: trunk/white-papers/dcom/relations.dia
===================================================================
(Binary files differ)


Property changes on: trunk/white-papers/dcom/relations.dia
___________________________________________________________________
Name: svn:mime-type
   + application/octet-stream


[prev in list] [next in list] [prev in thread] [next in thread]