db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "Tiago_Espinha" by TiagoEspinha
Date Mon, 19 Apr 2010 17:59:46 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The "Tiago_Espinha" page has been changed by TiagoEspinha.
http://wiki.apache.org/db-derby/Tiago_Espinha?action=diff&rev1=8&rev2=9

--------------------------------------------------

   * New test cases to verify that characters beyond EBCDIC are indeed supported
  
  === Schedule ===
- It is difficult to provide a clear schedule on this project as it will require extensive
changes throughout the whole client driver. It is not easy to have an understanding right
now as to how deep these changes will have to be. I do expect however to have the implementation
covered by the mid-term evaluations (July 16th) time by which I would start writing the test
cases.
+ 
+ ==== Section I - Problem Analysis ====
+  * 1st of April
+   * Studying the DRDA specification (chapter IV) to gain perspective on how it works.
+   * Studying the ACR7007 that specifies how the UTF-8 support should be integrated into
the DRDA engine.
+  * 8th of April
+   * Fix [[https://issues.apache.org/jira/browse/DERBY-4584|DERBY-4584]] as an ancillary
issue related to DRDA and non-EBCDIC characters.
+   * Starting to study the existing prototypes for this implementation.
+ 
+ ==== Section II - Implementation ====
+  * 30th of April
+   * By this date I expect to have an understanding of the prototype.
+  * 22nd of May
+   * Implement tests to analyze down the line whether the implementation has been done correctly.
+   * These tests will try to use UTF-8 characters in the RDBNAM, USRID and PASSWORD fields
and fail whenever the server throws an error.
+   * Tests are also needed to ensure that the length cap is maintained on these fields. When
only the EBCDIC implementation was available, 1 byte equalled 1 character. However, with UTF-8
in play, a character has variable length and can take up to 4 bytes. This means that the identifiers
can no longer have 255 characters but only 255 bytes.
+  * 12th of June
+   * By this date the first draft of the structure needed for the UTF-8 encoding should be
in place.
+   * This will require an Utf8CcsidManager that mediates the encoding from and to UCS2.
+   * It will also require changes wherever necessary to make sure that the CcsidManager is
used.
+  * 3rd of July
+   * After the aforementioned task is done, I will be implementing a switch mechanism that
will choose whether to use EBCDIC or UTF-8.
+   * This choice is based on the EXCSAT command and the level that has to be negotiated between
the client (Application Requester) and the server (Application Server).
+   * The encoding used will be the lowest common denominator between these two, as to maintain
backwards compatibility.
+   * I will also need to enforce the 255 byte cap to satisfy the DRDA specification.
+ 
+ ==== Section III - Testing and deployment ====
+  * 9th of August
+   * Check that backwards compatibility is maintained.
+   * This will entail testing the trunk server against a 10.1 client and a 10.1 server against
a trunk client.
+   * Check that the identifier cap is in place.
+   * Check that UTF-8 characters are indeed supported.
+ 
  
  === References ===
  [1] http://bit.ly/TiagoASF

Mime
View raw message