Changes between Version 4 and Version 5 of CsMapRfc5

Timestamp:

Jun 27, 2011, 11:45:03 AM (13 years ago)

Author:

Norm Olsen

Comment:

--

CsMapRfc5

@@ -25 +25 @@
 This RFC, proposes to remove the existing non-functional and commented out code (csThread) and add features which address the multi-thread safety issue in a more general, platform independent manner.  The result may not necessarily be a completely thread safe library, but a significant improvement in CS-MAP’s ability to perform in the multi-thread environment.
 
-This section briefly describes the problem set, and the proposed solution in general terms. It should be deliberately short, a couple of sentences or so. 
-
 
 == Terminology ==
@@ -41 +39 @@
 
 No changes are proposed for existing interfaces or core functionality, while some new functionality is proposed and will be exposed.  Two separate phases of solution are proposed, as each is essentially independent of the other and can be implemented, tested, documented, and released independently of each other.  Additionally, the proposal is such that the implementation of Phase Two can be spread out over time, and over several releases, without negative side effects.
+
+
 The proposed solution addresses the reentrancy of the actual coordinate conversion/transformation methods and algorithms only.  All methods, objects, and algorithms related to conversion/transformation object construction, dictionary meta data, dictionary maintenance, UI support, etc. etc. will remain as.  That is, by-in-large non-reentrant.
 
@@ -48 +48 @@
 Most all of the conversions and many of the transformations within CS-MAP are inherently reentrant and have been for some time.   In Phase One of this proposal, we simply provide information to the developer as to the reentrant behavior of any given conversion and/or transformation, or combination thereof.  Given this information, a developer can determine if using multiple threads is safe and/or if an exclusive lock needs to be applied to a specific portion of the entire conversion process.
 
-Implementation of Phase One will be accomplished by adding a new property to the projection flags element of the projection table.  Using this feature, each projection will be classified as being reentrant or non reentrant.  (Currently, only the OSGB variations of the Transverse Mercator which use the ordnance survey grid tables are known to be non-reentrant).  A similar feature was designed in the the Geodetic Trnasformation table, but is as yet unused.  Thuis feature will be implemented and each geodetic transformation method classified in the table as being either reentrant or not reentrant.
+Implementation of Phase One will be accomplished by adding a new property to the projection flags element of the projection table.  Using this feature, each projection will be classified as being reentrant or non-reentrant.  (Currently, only the OSGB variations of the Transverse Mercator which use the ordnance survey grid tables are known to be non-reentrant).  A similar feature was designed in the the Geodetic Transformation table, but is as yet unused.  This feature will be implemented and each geodetic transformation method classified in the table as being either reentrant or non-reentrant.
 
 Implementing the API's for this feature is then a matter of extracting the conversion/transformation method and extracting the reentrancy bit from the properties flag word of the appropriate table.
@@ -54 +54 @@
 === Phase Two ===
 Those CS-MAP conversions and transformations which are not reentrant are usually that way due to the heritage of CS-MAP (the days of the 640KB PC and no more than 8 files open at one time) and the level of resource consumption which would be necessary to achieve reentrant status.  In Phase Two of this proposal, all non-reentrant conversions and transformations for which reentrancy can be achieved without unreasonable additional resource consumption will be recoded to achieve reentrancy.
+
 Hubris might lead one to believe that the entire library could be re-written to achieve complete reentrancy.  While this is indeed the expected result, this proposal retains Phase One as necessary to:
  * insure that exceptions are not encountered, and to
@@ -77 +78 @@
  * In the event of an error, the test application lists the indicate the specific test conversion which produced the failure.
 
-It is expected that this test facility will be implemented using the environment of the MeatCRS’s OsGeo sibling MapGuide as the MapGuide environment is more readily adaptable to multi-threaded applications.
+It is expected that this test facility will be implemented using the environment of the MeatCRS’s OsGeo siblings, MapGuide, as the MapGuide environment is more readily adaptable to multi-threaded applications.