all the \LB services. There are bindings for other languages (C++,
Java) as well as web-service (WS) based interface, but these cover only
subsets of \LB functionality and internally they use the C API
-themselves (in the C++ case the C API also exported).
+themselves (in the C++ case the C API is also exported).
We describe the C API first and then the differences between C and the
other languages, as the C constructs often reflect directly.
job. \\
\end{tabularx}
\caption{Common job status attributes}\label{t:cstatus}
+
\end{table}
Job status structure is returned by the \LB consumer API job status
\TODO{Library dependencies - which rpms are needed?}
\subsection{C++ Language Binding}
-C++ language binding for the \LB library is not the (re)implementation
-of the library in C++; instead it is just a thin adaptation layer on top of the C
-API, \ie all the structures and functions of the C API can be used in
-C++. The C++ classes wrap up the concepts and structures of C API and
-provide convenient access to the functionality. The namespace used for
+The C++ languague binding now only supports the consumer (querying)
+API. It is not the (re)implementation of the library in C++; instead
+it is just a thin adaptation layer on top of the C API, \ie all the
+structures and functions of the C API can be used in C++. The C++
+classes wrap up the concepts and structures of C API and provide
+convenient access to the functionality. The namespace used for
\LB C++ API is \verb'glite::lb'.
\marginpar{Exceptions}%
Using this scheme all the data allocated by the \LB library are held
in memory only once.
+\marginpar{Context}%
+The context in C API is part of common components, the C++ API on the
+other hand differentiates between query context
+(see~\ref{ServerConnection}) and logging context; the description is
+therefore part of the respective chapters.
+
\subsubsection{Header Files}
Header files for the C++ version of common definitions are suummarized
in table~\ref{t:cppheaders}