Eric Lease Morgan wrote:
> On Mar 21, 2007, at 5:07 AM, Laurence Finston wrote:
> Cool, and interesting. I think I speak for the community when I
> sincerely say, "Good luck".
> The goals you desire to achieve with the software are the same sorts
> of goals many of us have. I'm sure some of us will install and
> experiment with the Exchange Utilities when they are easily
> installable on the platforms we support. Alas, many of us simply do
> not have access to Microsoft products.
This list is clearly not the place to discuss my personal situation,
but I will say that I need to find work in order to continue working
on this package. If I'm not employed _to_ work on it, I would work on
it in my free time. I think this kind of project could receive
funding from some institution, but I'm not in a position to apply for
it. One problem with Free Software is finding someone to finance it.
Using Microsoft products wasn't my choice. Visual Studio promotes a
style of programming that starts with the GUI and then adds
functionality to the buttons, edit boxes, etc. This is the opposite
of what I think is the "right" way to go about it. That's why I'm
building the new package around an interpreter that I've written using
GNU Bison. (Just in case anyone isn't familiar with this topic, Bison is
the GNU version of the UNIX utility `yacc'. Bison and yacc are "compiler
The sub-package `scantest' can be installed on GNU/Linux systems.
It should work on other UNIX-like systems, but I haven't tested
this. At present, it's a "toy" program, since it doesn't perform
a useful function, but it might be fun to try. I find it quite
enjoyable watching the output from Bison parsers, but perhaps I'm
I don't think a GUI is necessary for this package, but
one could be written. However, I would use a free library and
certainly not Visual Studio. I'm not personally a big fan of GUIs,
although they can be useful. An interpreter would also be useful in
combination with a GUI. However, for this purpose, I think an
interpreter for a machine-like language, and a scanner that reads
binary files, would be more useful. I've planned to write an
interpreter like this for my other package, GNU 3DLDF, but have never
had the time.
There are a lot of free tools, libraries, etc., for some of the tasks
involved, notably `libxml' for handling XML data and YAZ for
accessing Z39.50 servers. Much of the work will "just" be a matter
of combining them. I believe that a good approach would be to
program "filters" for the individual tasks I want to solve,
i.e., programs that read from their standard input and write
to their standard output. Such "filters" can be chained using
pipes. As I'm sure many of you know, this is a typical style of
programming in UNIX-like programming environments.
Of course, the filter programs could also have "side effects",
such as writing files. A great deal of my previous work has
involved Donald Knuth's TeX and related packages.
It's very easy to write programs that output TeX input files,
and it's possible to produce very high quality printable output
using TeX, usually in the form of PostScript or PDF files.
I will probably use TeX to represent the contents of the databases,
along with HTML.
At present, I'm very occupied with job applications. I also have to
perform some tasks resulting from the package having been accepted by
the GNU Project. For example, I must add the required options, change
copyright notices, work on preparing a release, etc.
When I've done something that might be of interest to readers
of this list, I will post an announcement. Under the circumstances,
it may be awhile before I'm able to devote the necessary time to