From: bgardner@ATHENA.MIT.EDU
Date: Wed, 8 Nov 89 19:33:55 -0500
Message-Id: <8911090033.AA10535@PINK.MIT.EDU>
To: argus2@ATHENA.MIT.EDU
Subject: Re: Message types...


   From: mackay@ATHENA.MIT.EDU
   Date: Wed, 01 Nov 89 21:21:26 EST

   I used the ruleeditor to select message type MSG.  It then ignored
   all the rules until I removed that field.  I thought "MSG" was
   supposed to be considered a general message (in other words, all
   messages are of type "MSG" unless specified otherwise).  I realize
   that this is a can of worms, since there are lots of problems with
   naming message types -- but can someone give me the rationale behind
   what we actually implemented, so that we can document it?  Thanks.

   W
 
 I had originally implemented this as a runrules-invisible field, so that
 runrules would not look for field type XXX.  Unfortunately, this still
 showed up in the rulebrowser because the ruleprint code doesn't take out
 fields which are not executed by runrules.  So we went ahead and said that
 if someone adds a new message type then it will check for a field called
 "Message-Type" XXX".  This kinda stinks, so I reccomend that in the
 documentation it tell people to remove that field.  This is a rule language
 limitation bug... I don't like it, but we wanted messages types.

         __Rich.

This is actually a number of bugs/mis-interpretations which snowballed.
Originally, the possible uses for a msg-type was abit blurred.
We'd considered "recognizing" msg-types by their fields, and several other
schemes...but we decided against them for various reasons (most of which I still
remember). What we finally decided was, that the rule editor would only
use msg-types in 2 ways....(1) was as a quick way of accessing all of the fields
associated to a msg-type, to save the user the time of typing them all in
(or having to remember them) -- if the user wanted to delete some of them, they
could; if the user wanted to add some, they could; and if the user wanted to 
combine fields from several msg types in their rule, they could do that too...
in other words, the user could ask to add the fields associated to some
msg-type to their rule and it would simple add them. (Note: it was a
convenience function, and was not meant for the msg-type to become a part
of the test in the rule).
(2) A user could test if a msg was of a particular msg-type by using
"Msg-Type:" as a field in the rule (for this, the ruleeditor would have to
offer a pop-up menu of known msg-types, and allow user type-in for unknown ones).
    When Rich got to impementing this in the ruleeditor, at first he tried
associating the msg-type to a rule. Since there was no mechanism in the rule language
for storing the type of a rule with the rule, he thought this was a bug
in the rule language. But actually, the typing is to type a message, not
a rule; which is why the rule language was not implimented with a Msg-Type
component (ie - the rule language was correctly implimented the way it was
originally designed, and whoever wrote the rule language did not omit
anything nor write a bug.)
To get around what Rich perceived as a bug in the rule language, he associated the
msg-type to the rule thru the only mechanism available -- the predicate.
He created an extra field in the rule, which was a predicate with no field
operator (and hence, a dummy field that would never fire). This dummy
field however showed up in the text output of Jeff's ruleprint function
(which it also should have...ie - not a bug).
    After the msg-type interface was implimented in the ruleeditor, and just before
the ruleeditor was put onto the release tape, Rich & I chatted about this problem.
And Rich altered the ruleeditor to replace the dummy field with a legitamate
"Msg-Type:" field. While this fix is pretty close to giving the correct end
result...it differs in one important way...the "MSG" msg-type was NOT meant
have a field called "Msg-Type: MSG" in it.
   To be done correctly, the Msg-Type Registry should be abit more sophisticated.
(Enough to know which types have a Msg-Type: field in them, and which don't...
Even if it was just a function like "AlMsgType_has_MT_field" which returns a
boolean, for the ruleeditor to reference before adding the new fields.)
   As it is, there's no "quick-fix", so Rich is probably right in suggesting
just to document it.
   The documentation should actually reference this fact for the other msg-types
anyway, so a general statement can be added....Something like,
"Selecting a msg-type for a rule is an easy way of adding the appropriate
fields to the predicate of a rule. The user should then fill in any of the
fields they with to use in their rule, and delete any fields they don't wish
their rule to test. Note that if the "Msg-Type:" field is not deleted,
then the rule will only fire if the message contains a field with a
matching "Msg-Type:" field in it."
   I think this will make reasonable sense to anyone who reads that
documentation. (Of course, most people probably won't read that documentation,
anyway...so many people will either not use msg-types, or will use them
successfully, but those picking msg-type "MSG" will probably have rules that
will never fire.
   Considering that we have a default set of predicate fields that come up
already...I'm not certain I understand why we need the option of a "MSG"
msg-type in either the msg-type registry or the ruleeditor's pop-up menu.
(I can't honestly think of what purpose it actually serves at this point...
it may well just be an unneeded left-over from the Info-Lens way of doing
things.)
    -- Brian