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

To sort or not to sort #59

Open
larsga opened this issue Oct 9, 2012 · 4 comments
Open

To sort or not to sort #59

larsga opened this issue Oct 9, 2012 · 4 comments

Comments

@larsga
Copy link
Contributor

larsga commented Oct 9, 2012

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.

@ihenriksen
Copy link

I think this is important. Also, I think it is a bad idea to let implementation specific concerns govern the specification work.

@tombech
Copy link

tombech commented Oct 12, 2012

I agree it is more useful than a "burden" on the server side

@ihenriksen
Copy link

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.

@larsga
Copy link
Contributor Author

larsga commented Oct 12, 2012

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.

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

3 participants