I discovered the Harp-L mailing list when I first started to try to play harp. Almost all of what I know about the theory of harmonica playing comes from this group. Much of what you read on The JT30 Page, HarpAmps.com and HarpTab.com(eventually) have their basis in something that I read in Harp-L.
I stopped reading the list in the late 1990's when it became so popular that it would take up half of my day just reading and responding to messages. Harp-L began to show signs of neglect at Garply. The system was slow and often broken and ceased to be a useful tool.
When garply kicked out harp-l the list went homeless for a while. The mail part of the list found a new home at harp-l.com, but the archives were orphaned. There is an incredible amount of original thought in the archives and I often searched it - even with the technical problems. When the archive disappeared, I really missed it.
Recently, I asked an innocent question about the archives of the list owners and I was surprised to get a positive response. I offered to host the archives for free. I did this for the technical challenge more than any sense of community. I like to tinker with things. That's why I play harp and fix old amps and write Java code.
On these pages I hope to create a searchable database of Harp-L messages from it's inception in 1992 up to 1999. If this works out, I will then add the subsequent years and create an interface for adding the new messages as they arrive.
All of my source code will be available to anyone who likes reading such stuff. I will point out that I have a distinct coding style and some purists may not approve of my approach. Anyone who wants to make helpful suggestions will be welcomed. Anyone who finds a bug will be praised. Anyone who criticizes my code will be murdered.
Phase 1. Convert data. The structure of the messages must be compressed. I need to clean up the messages, removing headers and footers and extract message date, thread and user information. I will create a repository of messages and an index of headers. The messages will be stored in a ZIP file. The index will be stored in a flat file. When combined I should be able to create a module which reads the index and composes a list of messages in any time frame. Clicking on any index will display the message in a frame.
Phase 2. I will create a second index of thread information. When a message is retrieved in a frame, another frame will show a tree of the message thread with the retrieved message in context. I will be able to directly go to any message in the thread and have next, previous, first, and last links for thread navigation.
Phase 3. I must create a way of searching the messages. The simple way would be to have a third party indexer spider the site. It would be a good idea to have Google spider the site so that the archives would be available to the world at large and also available using Google's site search tool. The alternative is to index the entire site using some utility and keep the index locally. This may be too expensive.
Phase 4. I would like to create a set of tools so that other sites can host a version of the archives, but with customized look and feel with their own graphics, banners and ads. Since each page is generated, (even though they will appear to be static to users) a page can have variable parts such as style sheets, graphics, banners and included code in headers and footers.
Phase 5. Move the next block of years into the archive.
Phase 6. Create a utility for keeping the archive up to date with current messages.
I get to play with neat code. I get to enhance the value of my harp sites. If it starts to cost me money, I will put a banner ad on some of the pages. Banner ads pay very little, but the archive should generate tens of thousands of page views a month and I figure it would cover any bandwidth or storage charges I would have to pay.
First, the archives are very large. Getting them compressed and creating a fast access index is a challenge.
My web host has a limited implementation of Tomcat and Java. They will not grant Tomcat the security to write to anything and that includes files and sockets. There can be no JDBC implementation of MySQL or any other database. I have to roll my own DB! (I think of this challenge as one of the cool parts of writing this system). Parts of the system such as adding new messages to the database will have to be written in PERL.
The Garply system written by Hugh Messenger was a gem of Perl coding. My system will be judged against a nice example of the programmer's art. I am a hack coder who likes to write minimalist systems. The systems that I design are small and simple. I don't think that I will be able to duplicate the feature rich system that Hugh created.