-
Notifications
You must be signed in to change notification settings - Fork 1
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
To sort or not to sort #59
Comments
I think this is important. Also, I think it is a bad idea to let implementation specific concerns govern the specification work. |
I agree it is more useful than a "burden" on the server side |
I would not worry about how the server implementation could handle this, there are software architecture design patterns (like different kinds of MVCC) that persist the data in a versioned and sorted order - therefore the client would not need any external sorting or post-processing after data syndicating. |
Thanks for commenting, guys. I'll start a discussion thread about this on the list. Please repost your answers there. I'm hoping that can "wake up" the others. |
Should entries in the fragment feed be sorted? Right now they don't need to be.
If we require them to be sorted, that makes life harder for the server.
However, if we sort by time ascending, that means clients can know that the time of the last entry is the highest time they've seen. So if processing breaks off on page 67 we can safely update the last seen time, and continue from that time next time around.
The text was updated successfully, but these errors were encountered: