sequential messages refactor

[ai10]

I am thinking to define a message as 'sequential' if the person who sends the message thinks it will be sequential, i.e., they have not received a newer message supervening their last message in a channel.

This has a couple of consequences.

1. A message can be tagged sequential once on the senders client when it is sent and obviate repeated post hoc calculations repeated across all clients.
2. The order of messages will be consistent with senders expectation in the event of race condition messages which may otherwise interrupt or supersede later posted message.

[rodrigok]

I didn't understand. Can you explain better?

[geekgonecrazy]

Seems like @ai10 is saying he wants some method to insure messages come through in the same sequential order as you sent them.

My question would be. Is a time stamp being sent on client along with the message? If so this is already not going to be a problem.

Also... I don't think even that is necessary. My understanding is the messages are essentially popped into an array as you send them. Then each is sent from the bottom of the stack or stream.

Unless there is an issue here? I'll experiment and see if I can come up with some sequencing errors

[rodrigok]

@geekgonecrazy exactly, there is one field called ts in every message, you can set this field in client to get the exactly timestamp and server will set this field if client doesn't.

All messages are sorted by this field, so, I don't think this necessary too,

[marceloschmidt]

Unless better explained, this is not an issue. If we find it otherwise, we can reopen.