Changes between Version 1 and Version 2 of CsMapRfc6


Ignore:
Timestamp:
07/24/12 07:16:31 (12 years ago)
Author:
baertelchen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • CsMapRfc6

    v1 v2  
    5555
    5656The proposed solution is to keep all aforementioned behavior but allow the hosting application to set a directory where all customized definitions should be stored in.
    57 In short, the following implementation would be affected:
    58  * Provide new CS_usrdir() API.[[BR]]
    59 This would have to exist in addition to the CS_altdir() API. If set, CS-MAP will store all custom definitions in that directory.
    60 New files will be created by CS-MAP, if not yet existing.
    61  * Change all relevant IO API for all types of supported definitions, e.g. [CS_*def()], [CS_*rd()], [CS_*del], … to include the files, if found, from the directory set by [CS_usrdir()].
    62 Note, that all that these methods, while implemented in separate C-Modules, all provide the same file IO functionality. In fact, most of the code is identical.
    63 To ease porting all that code to the new behavior, this RFC also aims for implementing a C++ module which would be internal to CS-MAP.
    64 That C++ module would centralize all relevant IO routines in templated functions and would expose its functionality through an “extern-C” wrapper module to CS-MAP.
    65 CS-MAP already contains other CPP files, too.
    66  * Remove all code that might keep the COORDSYS.CSD, DATUM.CSD and ELIPSOID.CSD files open after 1st usage.
    67 There should be one common behavior in how CS-MAP uses its *.CSD files – open, read/write, close. That schema has also been implemented for all new dictionary types.
     57In short, the following implementation would have to be done:
     58 * Provide new CS_usrdir() API. This would have to exist in addition to the CS_altdir() API. If set, CS-MAP will store all custom definitions in that directory. New files will be created by CS-MAP, if not yet existing.
     59 * Change all relevant IO API for all types of supported definitions, e.g. [CS_*def()], [CS_*rd()], [CS_*del], … to include the files, if found, from the directory set by [CS_usrdir()]. Note, that all that these methods, while implemented in separate C-Modules, all provide the same file IO functionality. In fact, most of the code is identical. To ease porting all that code to the new behavior, this RFC also aims for implementing a C++ module which would be internal to CS-MAP. That C++ module would centralize all relevant IO routines in templated functions and would expose its functionality through an “extern-C” wrapper module to CS-MAP. CS-MAP already contains other CPP files, too.
     60 * Remove all code that might keep the COORDSYS.CSD, DATUM.CSD and ELIPSOID.CSD files open after 1st usage. There should be one common behavior in how CS-MAP uses its *.CSD files – open, read/write, close. That schema has also been implemented for all new dictionary types.
    6861
    6962== Implications ==
    … …  
    7871
    7972
    80 Remove the following static variables from CSMAP and thus the option for an API client to specify how CSMAP would keep files open.
    81 As aforementioned, CSMAP would now always close any *.CSD file right after having used it.
     73Remove the following static variables from CS-MAP and thus the option for an API client to specify how CS-MAP would keep files open.
     74As aforementioned, CS-MAP would now always close any *.CSD file right after having used it.
    8275
    8376