There are two mail handlers, at least initially. One is the wftk-bare mail handler, which doesn't involve the repository manager and thus may be more useful for simpler installations. The other is the repmgr mail handler, which relies on the repository manager library to do its work. The wftk-bare manager uses a datasheet repository adaptor (dsrep) to create a datasheet corresponding to the mail it receives, while the repmgr handler uses a list adaptor to create a list entry. Otherwise they work substantially identically.
They share common code to do the work of parsing the mail. This code is in the mail_reader object file.
Further refinements at a later date might include the ability to recognize an incoming mail as related to an existing process, and attaching it to that process. I think it should be possible, however, to set up a procdef to do that automatically via script in some way even with the current mail handlers.
(July 26, 2002): In wrestling with this code, I have come to realize that the way
I'm dealing with disseminating information about static-linked adaptors frankly sucks. So my new plan
is to create a library system which includes the core code in one library (-lwftk, -lrepmgr), and
puts the local system's static adaptors into a second library which would be compiled to contain
the adaptors staticly linked on that system. This second library would be, say, -lwftk_a and would
then contain the function wftk_lookup_static_adaptors
; this function would be compiled
uniquely for each installation and would return the usual information about local static adaptors.
This code and documentation are released under the terms of the GNU license. They are copyright (c) 2002, Vivtek. All rights reserved except those explicitly granted under the terms of the GNU license. This presentation was prepared with LPML. Try literate programming. You'll like it. |