Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Questions

  • (tick) Should entities be allowed to have more than one associated message thread?    
  • (error) Or message threads to have more than one associated entity?
  • (error) 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?
      This will prevent unreasonable sending-lag and make it possible (if we want) to have real time chat.  (i.e limited to one user as a recipient)
    • (tick) Sending messages to non-principals (i.e. commenting on an entity) does not need asynchronous processing
    • (tick) Sending messages to a single recipient will be done transactionally
  • What ACCESS_TYPE should be associated with the ability to comment on an entity?
    • For now, I'm using the SEND(tick) SEND_MESSAGE type.  
  • What ACCESS_TYPE should be associated with the ability to message a user?
    • For now, there is no restriction
    • Blacklist (question)
    • Flag as inappropriate (question)(tick) No restriction
    • (tick) Add a blacklist
    • (tick) 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?
    • (tick)Add services to check if message can be sent.  This way, the UI can check if a message can be sent before sending it.  
    • (question) 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(question) Currently, it simply stashes the message, leaving no way of fetching the message (other than as a sender).  

...