The Connect class manages one connection to either a remote data set, via a DODS data server, or a local access. For each data set or file that the user program opens, there must be exactly one instance of Connect. Because information needed for local access is stored in an instance of Connect, this class may also be used (sub-classed) for each client API that needs to maintain additional information about the connection.5. In the API-specific child of Connect additional members can be added to store state information that the client-library needs to maintain the virtual connection (See Section 3.2 for more information on making virtual connections).
The Connect class provides member functions to get the dataset's DAS, DDS and data. The instance of Connect (or a subclass of Connect) stores the URL as the user provides it.
When the client library receives a URL via its "open" call (which
will not actually be called open but performs the function of
opening a file or data set; e.g., NetCDF's ncopen) it passes
that URL to the Connect member functions like
request_das and request_dds. These member functions
append an appropriate extension (.das and .dds, for
example) onto the URL and retrieve the resulting information from the
server, the DAS or DDS for the dataset.
If you are re-implementing an API and must support function calls that
modify how data is accessed (e.g., by creating array slices or by
choosing one of a set of variables), then you will need to translate
those requests into a DODS constraint expression. You would then pass
these synthesized constraint expressions to the
Connect::request_data member function. (See
Section 4.3 for more information about constraint
expressions.)
The specialized version of Connect is the place to put state information needed by a recoded API or other client. This can be used, for example, to emulate an API that maintains a list of open files.