Season's greetings and best wishes! "The next version of HSQLDB .... more features, enhancements, fixes, etc.... ."
In 2002, something like the above statement could have been made each month - the two releases were major milestones. Like most users and developers, I would like HSQLDB to become more resilient, run faster, use less resources, and have more features. The goal has always been the same but I think the way to achieve it has somewhat changed in the last twelve months. Until ten months ago, improvements were submitted as patches to a version that had been in circulation for a few months. Each developer focused on one area and made improvements, avoiding any side-effects that could impact other areas. This was the right thing to do at the time, but its cumulative effect was turning the codebase into a patchwork, even after the adjustments to make the patches work together. I must emphasise though, that certain code areas are semi-independent from the rest and an individual developer's focus on those areas can bring excellent results. Blaines's work, both on scripts and on SSL support is an example. In the last three months I have focused on the core classes that are responsible for indexing, persistence, recovery etc. These are the classes that provide the functions of a DBMS with some R but no SQL. I am not interested in buzzwords, but "cross-cutting concerns" came to mind all the time. The code was complex for lots of reasons, some valid, some not. The code base works very well as it is, or was a year or two ago. The issue at stake is managing its evolution. We need to refactor and apply the very basic tenets of structured programming to the remaining parts of the code so that we can see exactly what the actual "concerns" are. Only then can we distinguish between the real and "pseudo" concerns and group the real ones into functional groups that interact according to clear patterns. Clear patterns that best reflect the flow and consistency of data, not gratuitous use of "factory", "observer", "singleton" and suchlike. So I am asking for more developer participation. Do not assume that I or anyone else on their own can do everything. The initial focus is code clarity - analysis, clarification and modularization are needed. The next step will come naturally. There are lots of request for improvements from the user community which have to be fulfilled. I am also asking for more user participation. Have you ever looked at the Test*.txt files that come with the code distribution? Did you know that you can add your own DDL and other queries to those files and run the TestSelf application? What about the rest of the org.hsqldb.test classes? Has anyone used those frameworks to demonstrate the speed implications of a particular use-case? Anyone interested in compiling parts of a How To? Someone mentioned in the users mailing list that a database engine is now provided freely as part of the Windows platforms and so on. Free in this context means getting something extra for what we have paid - and most people welcome it. Free in our context means something more: that we are free to collaborate and change something to do what we want. Fred Toussi For the core areas ------------------------------------------------------- This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
