Dear DDJ,
The sample code included with my article, "The Java Provider Architecture" (DDJ, March 1999) was written using the Early Access release of the Java Cryptography Extension 1.2. I'd like to let readers know that, since the code was developed, a newer release of the JCE (Release Candidate 1) has been made available. Some of the minor changes and improvements made by RC1, most notably the change of the argument type of the constructor of class PBEKeySpec from String to char[] and the appearance of the additional methods engineInit() and engineGetParameters() in class CipherSpi, cause compile errors if you attempt to compile my code. To rectify this, simply add the two new methods to Enigma.java and make the appropriate change to the argument of the PBEKeySpec constructor in EnigmaTest .java.
Paul Tremblett
paul_tremblett@beechwood.com
Dear DDJ,
I am writing this, having just purchased the December 1998 issue of DDJ. As you can see, we're already into 1999, but that's not really my fault -- that's when the magazines get here.
The name D-Flat was originally stated as a relationship to C (the language you wrote it in, obviously), and a musical alternative to C sharp. "D flat is a difficult key to play in" was what I believe you wrote in at least one of your columns. I suppose you should call it a pun...I believe I still have most if not all of the original columns. I also managed to write some useful applications with it (all of which have now bit the dust thanks to Windoze).
So, do I win the invaluable (or was that valueless...) prize? (despite being the 1,527th respondent).
A.P. Madden
Australia
amadden@pcug.org.au
Al replies: Andrew, you might win the prize for the entry from the most distant location. Although, in this Internet era, that's a dubious distinction. I don't think I ever said that Db is a difficult key, but the rest of your memory is accurate.
Dear DDJ,
In the article, "A Java Applet Search Engine" (DDJ, February 1999), Tim Kientzle complained that he wasn't able to find any CD mastering package capable of generating hybrid ISO/RockRidge/Joliet/HFS (DOS/ Unix/Windows/Macintosh) CD ROMs. I am happy to say that his wish has been granted: mkhybrid, written by James Pearson (j.pearson@ge.ucl.ac.uk) is the program Tim was looking for. It is freely available in the source-code form at http://www.ge.ucl .ac.uk/~jcpearso/mkhybrid.html. Several other free CD mastering tools (including CD burning software, digital audio extraction tools, GUIs, and much more) are listed at the CD building project for UNIX (http:// www.fokus.gmd.de/research/cc/glone/ employees/joerg.schilling/private/cdb.html). Taken together, these tools make for a nice CD mastering environment indeed.
Serguei Patchkovskii
patchkov@ucalgary.ca
Dear DDJ,
Thanks to Tim Kientzle for his article "Full Text Searching in Perl" (DDJ, January 1999). DDJ readers might be interested in being able to search the generated databases from PHP3 (http://www.php.net/), the popular web-server language. They can find scripts that I wrote to make this possible at http://www
.heddley.com/edd/php/search.html.
Unfortunately PHP doesn't guarantee Berkeley DB support so I created a GDBM version as well, which doesn't work as fast, for those whose PHP implementations didn't do DB (although there is some information on the page for how to recompile your PHP for DB support).
There are also a couple of other alterations for PHP in there that get around the fact that PHP doesn't support NUL in database keys, and neither does it have the pack/unpack functions from Perl.
Edd Dumbill
edd@heddley.com
Dear DDJ
I enjoyed reading about Berkeley DB in "Full-Text Searching in Perl," by Tim Kientzle (DDJ, January 1999), but would like to respond to a few of the points Tim raised.
First, the performance and reliability problems that Tim reported were caused by using a several-year-old academic release of Berkeley DB. That version of the software has never been commercially supported and is known to have serious flaws. The current Berkeley DB release is API compatible with Tim's use, and suffers from none of the problems he listed.
Second, we have worked hard to make the current release easy to download and install. Regardless of the Perl module being used, we strongly encourage Perl developers to download and use the latest code.
Finally, while we have kept our interfaces intuitive and easy to use, Berkeley DB is not a "simple database." It provides the features that developers expect from high-end commercial offerings, including full transactional support, disaster recovery, hot backups, and scalability in both number of users and volume of data. Berkeley DB supports 100 GB databases in major commercial products just as easily as it does everyone's favorite Perl applications.
Michael A. Olson
Sleepycat Software
mao@sleepycat.com
Tim responds: Thanks for your note, Michael. Unfortunately, the current Berkeley DB 2.X is not file compatible with the Berkeley DB 1.85 I used. Consequently, neither will it work with the Java applet I presented in "A Java Applet Search Engine" (DDJ, February 1999). Interestingly, most of the problems I was experiencing disappeared when, thanks to a suggestion by Paul Marquess, I reduced the memory requirements of my Perl code.
Dear DDJ,
I enjoyed reading Al Stevens' "C Programming" column in the December 1998 issue of DDJ. I have been reading DDJ since another Al -- Al Williams -- was talking about "Roll Your Own DOS Extender" back in October 1990. Yes, I did give it a roll and enjoyed trying to use every security feature built into the 386 and finding out firsthand just why no one actually uses every security feature. Yes, like Al, I find research is important. I like to explore ideas and go deeply into software topic to find design inspiration.
As you might have guessed, I am a programmer and I am currently working for an organization in the financial services sector. There is a diverse mix of platforms and technologies, so I have plenty of variety, but most new development work is done in C and C++ and in which I have also had the most experience. I have worked on GUI application development for both Windows and OS/2 and find it very enjoyable. I think this is because it is both challenging and the results are visible, which is often not a programming outcome.
What interested me particularly about Al's column is that he is planning to embark on D-flat 2000 as I am currently working on a GUI application framework as a "research" project in my spare time. I'm calling my project "Classic" as it will be the culmination of all I have learned about GUI application programming, hence I hope worth preserving, plus the name contains "class," which is appropriate for an object-oriented design. Yes, I remember Al saying that D-Flat is the same as C-Sharp on the musical scale, hence a disguised way to get "C" in the name.
What struck a chord with me was Al's comment that "Recent forays into templates have convinced me that...templates are an ideal medium with which to express abstractions." I feel that it is essential to express abstractions clearly in one's code to combat the inevitable complexity that comes with developing significant applications. I agree that templates lend themselves readily to expression of abstractions. I have been particularly inspired in this regard by Jiri Soukup in his book Taming C++: Pattern Classes and Persistence for Large Projects (Addison-Wesley, 1994). He suggests ways to implement pattern classes, including using templates. I have taken some of these templates and developed them for use as a small foundation class library.
Taming C++ sums up my aspiration for the effect of using pattern classes in my application framework. I can clearly express the roles classes play and their relationships to each other. Up to now, such information always seems to disappear as implementation in code proceeds.
Currently Classic is a set of foundation classes and a tiny application that pops up a dialog box with two buttons and some static text. Not very exciting, but I like using the pattern class templates, and I think their potential is exciting. For example, I'm using a Composite class as a container for my menu bar, and it stores the menu items in a hierarchical structure that reflects the hierarchical menu structure. This is achieved in an unobtrusive way. I don't have to create any special functions or add any variables, the pattern behavior is acquired by simple inheritance.
Here is how I define class menu_component, from which I define menu_item and popup_menu:
class menu_component : public class_tag<menu_component>
...
Here is how I define the container to hold all menu components:
Composite<popup_menu, menu_component> menu_composite;
My adapted pattern classes are easier to use than the originals, but do suffer from some loss of performance. This is because I create the required infrastructure dynamically, while this is done in Taming C++ statically, at compile time. However, I don't think the loss of performance will be significant, especially because I have optimized iteration, which would be the most common method of object navigation. Furthermore, I will be able to create a "pattern class development tool" for class modeling and design.
Anyway, I encourage Al to proceed with D-Flat 2000. I would really like to see what materializes.
Andrew Bowley
bowley@enternet.com.au
DDJ