@device[postscript]

@heading[OLD SPEC]
@skip[2]

@section[Registry Object]

@b[Message type registry:]  Stores the names of the message 
type registries and paths to their locations.  Can accommodate 
message types from multiple files.

Athena Lens uses registries to keep track of different objects and
provide a consistent way to refer to and store them.  Registries can
be used in a hierarchical way, e.g. the message type registry.
Registries are usually passed a key and return a value.  Biregistery
are similar, except they can also be passed a value and return a key.
The is useful when a program retrieves a value from a registry,
operates on it, and returns it to the registry.

The following registries are defined in the Registry specification.
@begin[format]
@tabclear[]
@tabset[.5in, 2in]
@\@b[Field Type]        @\Fields within messages can be strings, dates,
@\                      @\lists of strings, etc.  This registry maintains
@\                      @\a list of the possible fields for a message.

@\@b[Message Type]      @\Message types are distinguished by the different
@\                      @\fields they contain.  This registry is has two
@\                      @\levels.  The first level contains a list of all
@\                      @\the message type registries.  The second level
@\                      @\contains the paths to each message type file.

@\@b[Rule Set]          @\Rule sets contain collections of rules and are
@\                      @\usually stored in a special directory.  This
@\                      @\registry keeps track of the different rulesets
@\                      @\in this directory and any others that are
@\                      @\registered when a rule is created.

@\@b[Verb]              @\Rules can perform different actions which
@\                      @\consist of a verb and an optional number of
@\                      @\parameters.  This registry keeps track of
@\                      @\which verbs are available and allowed.
@end[format]


@section[Why Not Just Use a Database Program?]

Database programs categorize and index large amounts of information
for quick retrieval.  This approach is useful in situations in which
the form and lifetime of the data is relatively stable and the
information is fully structured and known in advance.  In situations
in which a stream of information needs to be processed, but not
necessarily saved, another solution is necessary.@foot[An example of
such a high capacity stream of information would be the monitoring of
automated network statistics coming from workstations, servers, and
other devices on a network.  Another applications is the dynamic
monitoring of source trees, a time-consuming part of Project Athena's
release engineering process.] 

Argus provides a greater level of freedom and a broader definition of
"semi-structured" messages.  Senders of messages can add individual
fields to messages, independent of the message type.  They can also
change their minds about which message type is being created at any
point during the composition process.  Recipients of messages can
write rules based on either the fields, the formally-defined message
types or both.  In addition, arbitrary groups of users can create and
use private message types, in addition to formally sanctioned ones.

Argus allows users to create simple, graphically-based
filters for incoming messages.  In both, users create filtering rules
by filling in the blanks of a message and specifying a corresponding
action.  Argus permits users to choose fields of different types
(matching of text, date, booleans, and numeric arguments).  Argus also
goes beyond the actions normally associated with handling mail (move,
copy, delete, forward), and provides a full set of actions, including
the ability to run any arbitrary Unix program.  Additional actions
include the ability to run other sets of rules (or stop processing of
those rules) and to create or modify user-defined properties of a
message.  Any rule can run additional rules (or stop them).

Argus processes messages sequentially.  Thus, given a stream 
of messages in a folder and a set of rules, Argus will begin 
with the first message, apply each rule in turn, and then 
go to the next message, until each of the messages has been 
processed.

Argus rules contain fields that are grouped into boxes and a list of
actions to be performed if the rule's predicate matches a message.
The value of the field in the rule is compared to the value of the
corresponding field in a message and evaluated as either true or
false.  Groups of fields can be evaluated together, using the set
operators 'and', 'or' and 'not'.  (For example, a rule might 
check if the @c[to:] field contains "Smith" and if the @c[date:]
field is less than yesterday.)

Argus allows users to create a variety
of different rulesets, for different purposes, and to run them at
different times.  Thus, a user might have an everyday ruleset to be
run prior to reading mail, an "after-vacation" ruleset to be run upon
return from an extended time away, and a separate ruleset for cleaning
up old files and organizing them for future reference.  Argus 
allows users to nest rulesets and rulesets can be run from other 
Unix applications.

@b[How to check for a specific message type, e.g. Bug-Report:]

Rule looks at each field to see if it exists and then checks total
number of fields against number defined in the message type.  (Would
like to be able to look up a message type, within the rule, and check
it dynamically, rather than having to hardcode the rule.)

@subsection[folders]

There is a documented set of functions that the interface must provide
to Argus.  One needs no knowledge of the implementation of Argus,
other than the requirements of these interface functions, to create a
"folder".  The possibility of managing many different message sources
adds to the Argus user's power to create an effective generic
information handler.


