Date: Thu, 29 Jan 1998 13:52:07 -0600
From: escargo@anubis.network.com (David S. Cargo)
Message-Id: <199801291952.NAA21658@brutus.network.com>
To: calvin-ui98@dagobah.stwing.upenn.edu
Subject: project implementation ideas
I thought I should start the discussion about how we might implement
our project. It seems like we haven't had a chance to talk all together
for a while.
Here's my idea. The underlying implementation controls objects called
projects. Projects organize sources (where the mailboxes come from),
filters (more on this below), processing, archives, and
destinations (where the archives go to if not on the local system).
We have a gui with a file menu; with options for New, Open, Save, and
Save As. What are manipulated by the file menu are projects.
We have an Edit menu; the menu allows undo, and other operations as
we get them.
If you create a project, it will have no sources, no filters, the
user's home directory as the working directory, no archives, and
no destinations.
We could represent these different things in a tabbed box.
On each of these tabs, you can see the current list of whatevers.
On each of these you can select and edit an existing object, or
add a new one.
The sources can either be local, in which case all you need is a path
to the mailbox, or remote, in which case you need the host name (or IP
address), the user name, password, and path to the mailbox. Finally
there would the path to which the remote mailbox would be copied.
I think Corey is right and we won't provide any remote file browsing
(though that would be a rather interesting extension).
Initially there would be no filters. This implies that all the mailboxes
get combined together and put into one archive.
In the processing tab, the organizing of the local input files into the
order in which they are processed, the filters that get applied to the
input files, and the working directories get defined.
In the archive tab, the parameters that hypermail takes per output archive
would be set, which includes the input file, the output directory, the
label, the URL to other archives, and the URL to archive information.
On this tab I see a scroll box with a list of the archives and a panel
with the properties for the selected archive.
By keeping track of the input files, if there is only one, we can
default the archive input file to it if a new archive is being
created. If there are multiple input files, the default input file
would be where all the files would be combined.
The destinations would be the opposite of the sources. A destination
would have a local directory, a remote system host name (or IP address),
user name, password, and destination directory. You could have multiple
destinations for the same local directory.
By keeping track of the output directories, the local directories for the
destinations can be picked from an option list. For that matter, by
keeping track of the local source files and destination files, we can
gracefully handle the case where there is only one input and one output.
Without too much work, we have have a window at the bottom of our window
for displaying helpful hints. (This is relatively easy to in Tk.)
Once a user creates or opens a project, processing can be performed.
As each remote source is opened, we should show the status of that;
as each file is transferred, we should show that.
Since we won't be writing our own FTP client, we will have to see how
well we can decouple our interface from the program doing the actual work.
About filtering. So far, we have talked about three kinds of filtering:
a filter that can change the subject of a message based on the current
subject, a filter that can change the destination of a message based
on the subject, and a filter that can change the destination of a message
based on the subject and date.
Filters present a considerable design problem. At their maximum capability,
they are almost like a programming language. Some of the issues are,
how are filters defined (and edited) and when are filters applied.
I think filters ought to be named. There are probably three places
where it makes sense to apply filters. 1) On specific input files;
2) on all input files; 3) on output files. If you imagine a message
being taken out of a mailbox, you might want to filter it only if it
comes from a particular mail box (either changing the subject or
routing it to a particular destination). Or you might want to apply
a filter to set the destination to all messages. Or you might want
to alter subjects only for messages going to a particular archive.
I think this is complex, but managable.
Those my thoughts so far.
Now we have get some agreement about what this should look like.