Support/Live Chat/Node.js: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
(14 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== What? == | == What? == | ||
This page outlines the work being done to implement a server that will work with an AJAX-based Live Chat frontend. The goal is to eventually replace the existing Java-based Live Chat system. | This page outlines the work being done to implement a server that will work with an AJAX-based Live Chat frontend. The goal is to eventually replace the existing Java-based Live Chat system. | ||
<br> | |||
== Repository == | == Repository == | ||
The project has been codenamed "Inko" (Parakeet in Japanese). The repository for the new code is hosted on GitHub, at [http://github.com/endtwist/inko]. | The project has been codenamed "Inko" (Parakeet in Japanese). The repository for the new code is hosted on GitHub, at [http://github.com/endtwist/inko http://github.com/endtwist/inko]. | ||
<br> | |||
== | == API == | ||
See: http://wiki.github.com/endtwist/inko/web-api | |||
<br> | |||
== Roadmap == | |||
* | *June 10: Authentication | ||
** | **'''<sup>[√]</sup>''' Find existing Django session ID in cookie | ||
** | **'''<sup>[√]</sup>''' Extract Django session data from database | ||
** Add | **'''<sup>[√]</sup>''' Create new "chat session" ID cookie | ||
***Use modified Session library from Express to store data (in memory?) | |||
**'''<sup>[√]</sup>''' Retrieve chat permissions from database | |||
**'''<sup>[√]</sup>''' Add authentication check (against stored session) to each page load | |||
**'''<sup>[√]</sup>''' Automatically authenticate user upon first load of chat system, if logged in. Otherwise, redirect them to the login. | |||
* | *June 17: Basic Messaging | ||
** | **'''<sup>[√]</sup>''' Build "Message" object that will contain all of the important message data and serialize it into a json object | ||
** | **'''<sup>[√]</sup>''' Create a "Room" object that will allow both 1-on-1 and multi-user conversations to be initialized. | ||
** | **'''<sup>[√]</sup>''' Guests should only be allowed in one room at a time? | ||
**'''<sup>[√]</sup>''' How to hash room names/keep them private? | |||
**'''<sup>[√]</sup>''' /message -> allow users to create new Message objects with data | |||
**'''<sup>[√]</sup>''' Add filtering for messages that will strip any potentially-harmful data (<tags>, etc.) | |||
**'''<sup>[√]</sup>''' Add CSRF verification. | |||
**'''<sup>[√]</sup>''' /listen -> add listener for new Message objects using long polling | |||
* | *June 24: Watchers | ||
**'''<sup>[√]</sup>''' Allow authorized users (check perms) to join 1-on-1 rooms | |||
**'''<sup>[√]</sup>''' Messages in rooms should be broadcast to all users | |||
**'''<sup>[ ]</sup>''' Watchers should not be allowed to speak in rooms | |||
**'''<sup>[√]</sup>''' Add ability to pass conversations to other users | |||
**'''<sup>[√]</sup>''' Agent interface as reference implementation | |||
* July | *July 1: Non-Authenticated Guests | ||
** | **'''<sup>[√]</sup>''' Allow guests that are ''not'' authenticated to join the support queue. | ||
**'''<sup>[√]</sup>''' Setting and updating a user's status | |||
**'''<sup>[√]</sup>''' Agent-Agent private chat | |||
*July 6 - 10: Summit 2010! | |||
*July 15: Guest Interface | |||
* | **'''<sup>[√]</sup>''' Guest interface as reference implementation | ||
* | **'''<sup>[√]</sup>''' Chat queue status (queue positioning/time estimate) | ||
*July 22: Logging & Group Chat Permissions | |||
**'''<sup>[ ]</sup>''' Add ability to kick users from chatrooms. Ban? | |||
**'''<sup>[ ]</sup>''' Message/conversation data needs to be logged somewhere | |||
<br> | |||
=== | === Notes === | ||
*Agents must be approved before they can pick questions from the chat queue. This is currently the "Live Chat helpers" group on sumo | |||
*Also, room monitors have permission to watch any chat room, open/close the queue, and set other helpers' limits. | |||
=== Chat queue features === | <br> | ||
* Ability for up to 50 people to be waiting in queues at once | |||
* Fair dispatching of requests to available helpers, based on specific criteria | == Features currently used in Live Chat XMPP server == | ||
* Ability of helpers to set their chat limit | |||
* Access levels to determine who can receive questions from the queue | === Core chat features === | ||
* "Room monitoring" ability that allows privileged users to join or monitor any chat in progress | |||
* Metadata associated with each room entered by the user being helped, including question/OS/version/useragent/plugins/etc (AAQ) | *Automatic scrollback log when users join a conference | ||
* Tag data associated with each room, either entered by helpers or automatically detected | *Individual status for each signed in user. (Online/Away/etc) | ||
* Integration with CSAT surveys to track which chats are successful | *Private messaging between conference members | ||
* Integration with support forum for users who need to follow up | *Storage of all logs, along with metadata, in a database for later access | ||
* Ability for a monitoring helper to take over a conversation | *Wiki formatting and links | ||
* Ability for privileged users to open/close the chat queue | *Individual messages up to 30KB each | ||
* Automatic chat queue status based on number of people signed in and the number of people waiting. | *Chat sessions up to 2MB each | ||
* Give people waiting in queue updates on their current queue position | *Notification when another user is typing | ||
*Join/part notifications | |||
*Topic for each room | |||
*Ability to invite other users into a conference | |||
*Up to 50 users chatting at a time in up to 50 conferences, with up to 600 combined messages per minute | |||
*Access control for users in conferences | |||
**Permission to join | |||
**Permission to invite | |||
**Permission to kick | |||
**Permission to set the topic | |||
=== Chat queue features === | |||
*Ability for up to 50 people to be waiting in queues at once | |||
*Fair dispatching of requests to available helpers, based on specific criteria | |||
*Ability of helpers to set their chat limit | |||
*Access levels to determine who can receive questions from the queue | |||
*"Room monitoring" ability that allows privileged users to join or monitor any chat in progress | |||
*Metadata associated with each room entered by the user being helped, including question/OS/version/useragent/plugins/etc (AAQ) | |||
*Tag data associated with each room, either entered by helpers or automatically detected | |||
*Integration with CSAT surveys to track which chats are successful | |||
*Integration with support forum for users who need to follow up | |||
*Ability for a monitoring helper to take over a conversation | |||
*Ability for privileged users to open/close the chat queue | |||
*Automatic chat queue status based on number of people signed in and the number of people waiting. (Must automatically close when the queue is "full") | |||
*Give people waiting in queue updates on their current queue position | |||
<br> | |||
== Staging == | |||
* Software requirements are outlined in the repo: [http://github.com/endtwist/inko http://github.com/endtwist/inko] | |||
* The server needs to daemonize itself. | |||
** PID should go into /var/run/ | |||
** Log file should go into /var/log/ | |||
*** It would be best to rotate logs with logrotate. | |||
* Restarting the server occurs how? |
Latest revision as of 16:10, 30 July 2010
What?
This page outlines the work being done to implement a server that will work with an AJAX-based Live Chat frontend. The goal is to eventually replace the existing Java-based Live Chat system.
Repository
The project has been codenamed "Inko" (Parakeet in Japanese). The repository for the new code is hosted on GitHub, at http://github.com/endtwist/inko.
API
See: http://wiki.github.com/endtwist/inko/web-api
Roadmap
- June 10: Authentication
- [√] Find existing Django session ID in cookie
- [√] Extract Django session data from database
- [√] Create new "chat session" ID cookie
- Use modified Session library from Express to store data (in memory?)
- [√] Retrieve chat permissions from database
- [√] Add authentication check (against stored session) to each page load
- [√] Automatically authenticate user upon first load of chat system, if logged in. Otherwise, redirect them to the login.
- June 17: Basic Messaging
- [√] Build "Message" object that will contain all of the important message data and serialize it into a json object
- [√] Create a "Room" object that will allow both 1-on-1 and multi-user conversations to be initialized.
- [√] Guests should only be allowed in one room at a time?
- [√] How to hash room names/keep them private?
- [√] /message -> allow users to create new Message objects with data
- [√] Add filtering for messages that will strip any potentially-harmful data (<tags>, etc.)
- [√] Add CSRF verification.
- [√] /listen -> add listener for new Message objects using long polling
- June 24: Watchers
- [√] Allow authorized users (check perms) to join 1-on-1 rooms
- [√] Messages in rooms should be broadcast to all users
- [ ] Watchers should not be allowed to speak in rooms
- [√] Add ability to pass conversations to other users
- [√] Agent interface as reference implementation
- July 1: Non-Authenticated Guests
- [√] Allow guests that are not authenticated to join the support queue.
- [√] Setting and updating a user's status
- [√] Agent-Agent private chat
- July 6 - 10: Summit 2010!
- July 15: Guest Interface
- [√] Guest interface as reference implementation
- [√] Chat queue status (queue positioning/time estimate)
- July 22: Logging & Group Chat Permissions
- [ ] Add ability to kick users from chatrooms. Ban?
- [ ] Message/conversation data needs to be logged somewhere
Notes
- Agents must be approved before they can pick questions from the chat queue. This is currently the "Live Chat helpers" group on sumo
- Also, room monitors have permission to watch any chat room, open/close the queue, and set other helpers' limits.
Features currently used in Live Chat XMPP server
Core chat features
- Automatic scrollback log when users join a conference
- Individual status for each signed in user. (Online/Away/etc)
- Private messaging between conference members
- Storage of all logs, along with metadata, in a database for later access
- Wiki formatting and links
- Individual messages up to 30KB each
- Chat sessions up to 2MB each
- Notification when another user is typing
- Join/part notifications
- Topic for each room
- Ability to invite other users into a conference
- Up to 50 users chatting at a time in up to 50 conferences, with up to 600 combined messages per minute
- Access control for users in conferences
- Permission to join
- Permission to invite
- Permission to kick
- Permission to set the topic
Chat queue features
- Ability for up to 50 people to be waiting in queues at once
- Fair dispatching of requests to available helpers, based on specific criteria
- Ability of helpers to set their chat limit
- Access levels to determine who can receive questions from the queue
- "Room monitoring" ability that allows privileged users to join or monitor any chat in progress
- Metadata associated with each room entered by the user being helped, including question/OS/version/useragent/plugins/etc (AAQ)
- Tag data associated with each room, either entered by helpers or automatically detected
- Integration with CSAT surveys to track which chats are successful
- Integration with support forum for users who need to follow up
- Ability for a monitoring helper to take over a conversation
- Ability for privileged users to open/close the chat queue
- Automatic chat queue status based on number of people signed in and the number of people waiting. (Must automatically close when the queue is "full")
- Give people waiting in queue updates on their current queue position
Staging
- Software requirements are outlined in the repo: http://github.com/endtwist/inko
- The server needs to daemonize itself.
- PID should go into /var/run/
- Log file should go into /var/log/
- It would be best to rotate logs with logrotate.
- Restarting the server occurs how?