JPBIFF ------ JPBiff is a biff style mail checking program written in Java that will check mail on a POP3 server. The name stands for Java POP Biff. I have tried to make the code as flexible as possible such that it should be able to relatively easily add support for other mail protocols, particularly IMAP4. COPYRIGHT NOTICE ---------------- JPBiff is Copyright 1997-1998 Chris Ingram. You may modify and redistribute the code under the terms of a BSD style license which basically only requires that you give credit to the author of the software. See the comments at the top of each source file for details on the license. The text of the license is included here for convenience: Copyright (c) 1997-1998 Chris Ingram All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. AUTHOR ------ Chris Ingram. Please send comments, suggestions, patches, etc. to Chris.Ingram@acm.org. You should be able to download the latest version of JPBiff from my web site at http://www.purl.org/net/cingram/. I welcome changes to the code that make the program better. COMPILING --------- First, you will want to update the hard coded values in Configuration.java that are specific to your server, account, and prefrences. Then, to compile the program with the JDK 1.1.x, change to the directory where you unarchived the code and type "javac jpBiff.java". You will get a warning about using depricated methods related to AWT objects. If you pass the "-deprecation" flag to javac, it will print more details about exactly which deprecated methods are being used. The reason for the deprecation warnings is that I originally developed this with JDK 1.0.2. JDK 1.1.x changed a lot about the AWT (such that it is supposedly better). Particularly, the addition of the Listener object registration methods. I don't know squat about the 1.1.x AWT. I have mainly developed this program on my Linux box at home, but I wrote it in Java so that I can also use in on my Windows NT box at work. I currently don't use it in either place. If you want to start poking around with the source code or figure out why something is not working, I highly recommend that you set the debug constants to true in jpBiff.java and POP.java. This will print extra information to the terminal (if you run the code from a command prompt) about each connection to the server. MAJOR THINGS REMAINING ---------------------- These are the major things I would want to have done before releasing a 1.0 version of this program. 1. Configuration: Currently, all of the identifying information such as POP server name, user name, password, poll interval, etc. is hard coded into the configuration object. There is no way to change this without modifying the Java source code and recompiling it. I added some windows for configuration purposes. My idea was that one window would have a bunch of text boxes that let you type a server name, user id, password, interval between checks. However all code in that arena is commented out. The configuration object is functional, but should be changed such that it can write itself to a file and initialize itself from a file. It should also be able to parse command line options which would override anything read from the file. 2. Save state to file: The program should be able to save the list of seen messages to a file such that the next time it starts, it can initialize itself with the list of messages that have been seen. 3. Header Display: Currently, when you click the mouse inside the window, if the flag is up on the mailbox (as it is when it detects new mail), the flag goes down. I want to change it such that clicking the mouse in the window brings up window containing a list of headers, particularly From and Subject. All headers should be shown with new ones in a different color (perhaps red for new messages and black for old messages) in descending order. All this information is already tracked, it is just never displayed in a window to the user. My idea was that there would be four buttons at the bottom of the header display. The first allows you to mark all of the messages as read (which has the effect of lowering the flag). The second checks the POP server for new mail without waiting until the next poll. The third brings up the configuration window. The fourth closes the header display window. 4. Convert to new AWT event model: I wrote this using the 1.0.2 AWT event model. A lot of that was deprecated in the 1.1.x series. That is why you have to specify the "-deprecation" flag to the javac compiler. Supposedly the way things are handled in 1.1.x is much simpler and cleaner, but I don't know anything about it. CVS TAGS -------- I am using CVS for version control. The tags include the version number and look something like "r1_0_1". The first digit is the major version number; the second is the minor version number; and the third is the build number. The build number should be incremented occasionally for compilable states of the code. Eventually, when it becomes time for a release of the software, the a tag will be added that is equivalent to the final build tag but with "release" for the build number. For example if "r1_0_28" is the build that I have decided to release as "Version 1.0", then I will create another tag called "r1_0_release" which identifies the equivalent revision of the code as "r1_0_28". After a "release", then the minor version number will be incremented on the next tag with the build number reset to 1. In the example above, after the release, coding would continue and the next tag would be "r1_1_1", then "r1_1_2", etc. If it becomes necessary to apply a bug fix to the "r1_0_release" a branch will be created called "r1_0_patch". The first released set of bug fixes will be labeled "r1_0_patch_1". The next will be "r1_0_patch_2", and so on. Patches made to an old release will be incorporated into the current build (the main trunk) if appropriate.