Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server enhancement: save last few chat messages #52

Open
ghost opened this issue Jun 2, 2016 · 5 comments
Open

Server enhancement: save last few chat messages #52

ghost opened this issue Jun 2, 2016 · 5 comments

Comments

@ghost
Copy link

ghost commented Jun 2, 2016

It would be nice if the server saved the last few (say 20) chat messages (in a FIFO stack).
Then when a client connects the server could serve up those last 20 messages.

@TreffnonX
Copy link
Contributor

FIFO stack is called queue or Deque ;) - but the idea seems pretty nice.

@ghost
Copy link
Author

ghost commented Jun 5, 2016

I see that the "shout" message (from the server to the client) doesn't include a timestamp... thus, the client has the responsibility to label each message with the time that it was received, rather than the server remembering when it was received from the originating client. Sending the saved messages to a new client would be less meaningful than if they had a timestamp to provide some context.

@TreffnonX
Copy link
Contributor

It's not a crux to add time stamps. Timestamps are usually longs. In this case a lot can be omitted, meaning that the time stamp would be a few characters to a message.

@ghost
Copy link
Author

ghost commented Jun 5, 2016

Right, I wasn't worried about the additional payload only that this would likely mean a change to the protocol.

It looks like the client simply ignores any messages it doesn't recognize. If that's the case it might make sense to add a new message, eg:
CatchupShout text
An old client would simply ignore it. An updated client would handle these new messages to load the chat window with these previous messages (converting the timestamp from GMT to the client's local GMT offset).

The current "Shout" protocol would not need to change. The client would continue to handle the timestamping of the messages as it currently does.

@TreffnonX
Copy link
Contributor

Since all clients are web-based, it's not a long-term issue. Just update all clients once and the problem goes away on it's own. Chaitu does let all people who run a client know in advance when a protocol change takes place. So it is a minor problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant