Page Comparison

...

•  Should entities be allowed to have more than one associated message thread? 
  
  • A:  Yes.  A "thread" is just a linked list of messages, linked by their inReplyTo reference, which is optional.  The ID of the thread is just the ID of the first message in the list, which has an empty 'inReplyTo' field.  So if more than one message is 'sent to' an entity (as part of a discussion forum) with an empty inReplyTo field, then there is more than one thread for the entity.
• Or message threads to have more than one associated entity?
•  Should we allow messages to be sent to multiple non-principals at once?
• Should messages with low numbers of recipients be processed in an immediately consistent manner?
  •  Sending messages to non-principals (i.e. commenting on an entity) does not need asynchronous processing
  •  Sending messages to a single recipient will be done transactionally
    
• What ACCESS_TYPE should be associated with the ability to comment on an entity?
  •  SEND_MESSAGE
• What ACCESS_TYPE should be associated with the ability to message a user?
  •  No restriction
  •  Add a blacklist
  •  Flag as inappropriate
• Should the worker use SQS or RDS to manage the flow of messages to send?
  •  Proposed RDS implementation:
    • Add a migratable table with a single column of message IDs
    • Add a worker that periodically polls the table
    • If the table is not empty, process N rows from the top
    • Delete rows once finished processing
  • Using SQS opens up the possibility of losing messages (especially during weekend stack switching).  The state stored in SQS would not be migrated between stacks.  And unlike change messages, there is no trivial method to detect if a message has been changed.  And reusing the change messages is not possible, since retransmission of messages is incorrect behavior. 
• How should we bounce messages?  Silently?  Via an auto-generated message?
  •  Add services to check if message can be sent.  This way, the UI can check if a message can be sent before sending it.  
  •  On an error, send an error message to the sender's inbox.
• How should we handle messages sent to groups rather than individuals?  Should the message be broken into individuals messages (after checking for SEND_MESSAGE permission on the group)?  
  •  Currently, it simply stashes the message, leaving no way of fetching the message (other than as a sender).  

Objects

...