I'm curious to hear some thoughts on code organization from the experts here. While looking at the code, the following issues seemd interesting:
1. Some of the terms used are not immediately obvious (perhaps just to me?):
DRDA (network code?), IAPI (interface api?), (vtit...?), noputresultset (NoPut ?)
2. Is it necessary to keep implementation and interfaces in completely seperate packages (impl | iapi)...since implementation packages contain abstract classes? What about simply refactoring interface files and adding an 'I' in front to distinguish...many implementation classes already have *Impl* in their name. Basically this will reduce the number of directories and packages one has to traverse to find the right set of code files.
3. If I remember correctly, org.apache.derby.*.sql package has around 500 files, ...sql.execute has about 150 files. Could this be broken out more? For example, couldn't the various CursorResultSet derivitives have their own package...so even a quick look at just packages gives an overview of the architecture?
4. Combining 2 and 3 will likely make it easier to follow the grammar file.
As I mentioned earlier, these were some of my impressions from having just started looking at the code. I realize that refactoring the code won't make any functional improvements but it will be beneficial from a usability perspective...since large number of 'users' of this code will actually be developers looking to get familiar with the code and contribute.
Falcon
btw: Dibyendu et al's documentation looks great. I can't wait to see such papers regarding higher level functionality!
