--- libxds.tex 2001/08/09 13:38:00 1.6
+++ libxds.tex 2001/08/09 13:53:47 1.7
@@ -1,6 +1,6 @@
% -*- mode: LaTeX; fill-column: 75; -*-
%
-% $Id: libxds.tex,v 1.6 2001/08/09 13:38:00 simons Exp $
+% $Id: libxds.tex,v 1.7 2001/08/09 13:53:47 simons Exp $
%
\documentclass[a4paper,10pt,pointlessnumbers,bibtotoc]{scrartcl}
\usepackage[dvips,xdvi]{graphicx}
@@ -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}
|
