Both ROLE and Awareness need support for threaded asynchronous discussions. The CCIT (and many other similar tools) provides a reasonable model for the web UI, and recent discussions among the Awareness project team suggest that something like a "public inbox" would be a useful interactive presentation.
A discussion is essentially just a tree of messages where each message includes:
- The author's name
- The time and date of the message
- List of users who have read the message
- List of references to responses
- The message text
Security issues:
- Modifying an EODescriptor requires write access to the parent
- Generally don't want to allow messages to be deleted.
- This could be done by no-oping the delete operation
- Need to be able to control re-editing of messages
- Maybe just allow re-editing of top level?
- Disabling write access isn't an option, since people need to be able to add new responses
- Just let versioning handle this?
Root node and editability issues:
- For use as a "public inbox" (as in the proposed email-substitute for the awareness project), it probably does not make sense to show the "root node" of a discussion as a message.
- The node could be used for explanation of the discussion object contents. The root probably still shouldn't be shown in the interactive view. ("Show root node" could be a per-discussion configuration option in the interactive client.)
- The threaded view may not be appropriate for "public inbox" use
- Responding to the root node should (never?) result in the subject defaulting to Re: Root Node.
- At least the root node should be editable, though versions should be preserved and clearly indicated. It might make sense to do this on all nodes, to support typo correction.
- It should be possible to mark threads as "archived", taking them off the page (but accessible through a link) and making them read-only (no editing, no replying)
Interactive View
- Shows message, rendered using same mechanism used in template browser
- Shows reply and edit buttons, if allowed
- If "top-level", also shows:
- table/tree browser
- buttons for configuration options
- Option to pop up window when new messages arrive?
Web View
- Shows message (rendered as a TextData, like any other basic web page)
- Shows parent links (if any) at top
- Shows children at bottom, with recent and unread messages indicated
- Configurable to show either just links (with subject, date, and author) or full/partial messages
- Has reply link
- Suppress edit operation? (Could also just indicate that the message has been edited and point the user to the "history" operation)
What else is needed to support weblog-style sites?
- Options for changing embedded sorting order (e.g., show most recent items first)
- Options for showing expansion n levels deep in embedded view
Imp notes:
- MessageDigest/GlobalClock-based mechanism for finding unread messages?
- Access to header (author/date/subject) and read/unread state needs to be fast; access to structure info needs to be somewhat fast; access to message content can be slow
- Tradeoff: Lots of objects vs. slow access
- Generic "Message", is an EOSet?
- Or object that contains an EOSet, which CV then presents
- Existing hierarchy mechanism maintains structure?
- Would "flat" list (ordered by time) also be needed?
- Would also need to imp TextData?
- Or ref TextData object outside of hierarchy?
- Potential problem if Messages become movable
- Where are formatting options?
- In each Message object? (and hierarchy searched until one is found)
- In a separate object (hierarchy searched until one is found)
- How to allow add but not delete?
- Message object could simply no-op the delete operation
- Permissions (and clarity) may force us to have two distinct kinds of objects:
- Discussions, which are groups of related messages
- Messages, which are also groups of messages, but with different operations?
- Or just have behavior change based on parent? (e.g., if parent isn't a message, allow re-editing)
- Should explore notion of linking as means for converging threads (e.g., same subthread could exist in different threads)
|