Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA12101; Tue, 21 Jun 88 12:10:14 EDT
From: <mackay@ATHENA.MIT.EDU>
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA02856; Tue, 21 Jun 88 12:10:09 EDT
Received: by E40-368-1 (5.45/4.7)
	id AA04620; Tue, 21 Jun 88 12:09:47 EDT
Message-Id: <8806211609.AA04620@E40-368-1>
To: rap@ATHENA.MIT.EDU, bgardner@ATHENA.MIT.EDU, jbs@ATHENA.MIT.EDU
Subject: re: my note about outgoing mail rules
Date: Tue, 21 Jun 88 12:09:44 EDT


------- Forwarded Message

Sender: Thomas_Malone@XV.MIT.EDU

Message type: Message
Keywords: 
Creator: 
Comments: 
Re: Message of 20-Jun-88 19:24:16

Wendy,

I like the "tickleby" example a lot:

1.  I think the idea of "optional" fields in message types makes a lot of sense.  This is better than a fixed set of fields because you don't need to have all the unnecessary fields hanging around all the time (like Reply-to, and Keywords in the current version of Object Lens).  I think it is also better than just trying to figure out the message type from the fields that are present.  This way, you know from the message type what fields make sense in a given context, even if they are not all present.  A question:  How to tell users what fields are optional in a given message type?  Should we use something like the "options" icon used in Common Lens (and viewpoint)?

2.  The idea of rules that fire on outgoing messages also makes a lot of sense.  We should be sure Object Lens has hooks to make this another kind of trigger for agents.  In the current Object Lens paradigm, agents are always applied to a folder.  Does it make sense to have all outgoing messages belong to an implicit folder or is there a better way to think of this?  (Second thought:  Why not just let the default be that you copy yourself on all messages or let people explicity copy themselves when they want something to happen locally about the message.)

3. One way of handling the the timelimit is this:   It seems that messages for which you want to be tickled by a certain date if you haven't received a reply are often (necessarily?) action requests.  These action requests would already have a field for "deadline", so you can just set up rules to look at this date and tickle you if some amount of time has passed since the deadline.  Rather than checking at that time to see if a reply has been received, it might make more sense to check at the time the reply is received to see whether the message to which it is replying is in a "pending" folder, and if so, move it or change its state somehow.---We need to think this through more clearly...  It probably makes sense to reify the notion of conversations more strongly and automatically keep all messages connected (through links) to the other messages in the same conversation.  Then, I guess, it would be easy to check at deadline time whether a reply has been received.

4.  Another question:  Do we want the receiver of the message to see the "tickleby" field established by the sender?  Probably not always.  Can we think of an elegant way for senders to store state about objects that is not transmitted to receivers?

t

 



------- End of Forwarded Message

