Index: ossp-pkg/xds/docs/libxds.tex
RCS File: /v/ossp/cvs/ossp-pkg/xds/docs/libxds.tex,v
rcsdiff -q -kk '-r1.6' '-r1.7' -u '/v/ossp/cvs/ossp-pkg/xds/docs/libxds.tex,v' 2>/dev/null
--- libxds.tex	2001/08/09 13:38:00	1.6
+++ libxds.tex	2001/08/09 13:53:47	1.7
@@ -1055,7 +1055,54 @@
 
 \subsection{What are those xds\_int-something types good for?}
 
-\subsection{Why do I have to register the engines manually?}
+\subsection{Why do I have to register all the engines manually?}
+
+One idea that came up during the design of the API was to provide a way to
+register all elementary XML or XDR engines with a single function call,
+something like this:
+ %
+\begin{quote}
+\begin{verbatim}
+xds = xds_init(XDS_ENCODE, XDS_XML);   /* Use the XML engines. */
+xds = xds_init(XDS_ENCODE, XDS_XDR);   /* Use the XDR engines. */
+\end{verbatim}
+\end{quote}
+ %
+The advantage of this approach is that the application developer does not
+need to bother about registering some obscure functions like
+\textsf{xdr\_encode\_octetstream()}. We dismissed the idea nonetheless for
+the following reasons:
+
+\begin{itemize}
+
+\item Since the library is meant to be extensible, the \textsf{xds\_init()}
+has no (good) way of knowing which engines actually exist for an encoding
+scheme. Suppose someone writes a whole set of engines that implement the
+CORBA format, then he would not be able to register his engines without
+re-writing \textsf{xds\_init()}.
+
+\item On a similar note, the \textsf{xds\_init()} would not know about the
+meta engines required by the application developer. The call outlined above
+would only register the engines for the elementary data types, for the very
+good reason that the meta engines do not even ``exist'' when the XDS
+library is compiled.
+
+\item This approach would make it hard to mix engines from different
+formats. If all engines are registered manually, the application programmer
+may chose to use the XDR format for encoding all kinds of integers, but to
+use the XML format for encoding strings, octet streams, or floating point
+numbers.
+
+\item If one routine would reference all engines of an encoding format, it
+meant that all engines of that format were linked into the binary once the
+application accesses that routine. It would not be possible to, say,
+register the engines dealing with integers without pulling the floating
+point engines into the program too --- even though nobody uses them.
+
+\end{itemize}
+
+
+
 
 \begin{thebibliography}{xxx}