Perhaps I should have clarified that the idioms I described illustrate exactly why it is rather heavy to guarantee stable collection iteration, and why I don't think it's needed here. What you ... [More] proposed, Josh, is an inexpensive compromise with good properties. I do think it only has the stated properties if "the field you sort on" is an identity for the items, yes? But that is probably a reasonable limitation to impose. [Less]

Yes, "stateless" and "paged results" don't mix. Somebody has to maintain some state if you want stable paging. Here are two reasonable and common approaches to stable iteration of a collection over ... [More] HTTP: 1) If the server is willing to manage a result set for the client and dole it out in pieces, have a means for creating a stable collection view (e.g. POST a query form to /getview), which responds with a 201 Created status code and a Location header supplying a URI handle to the collection (e.g. /views/fb07a1). Further operations based at that URI (e.g. /views/fb07a1/p1, /views/fb07a1/p2) are understood to apply to the created collection view. For very large or active collections, one simply might not be able to guarantee that the collection view was stable over time; to signal the client to start over with a new result set based on the same query, HTTP semantics like 301 Moved Permanently can be useful. (This is kind of like a Java collection throwing a ConcurrentModificationException). Collection views accessed after the server is no longer willing to persist them can be met with 410 Gone. 2) If the client is smart enough and you don't want to create server resources at all, you can make the client responsible for all paging of collections. The initial request from client to server fetches a complete list of matching object or row IDs comprising a snapshot of the collection, and each paged request then explicitly asks for a sequence of those IDs. Addition of an item to the collection by a third party is unknown to the client unless the client re-requests the list; deletion of an item from the collection is equally unknown; deletion of an item altogether results in a failure to retrieve that item (404, null in a list, etc). Of course, you need to be working with collections small enough that their entire ID set can be downloaded in reasonable time. But to be honest, I'm not sure that stable collection iteration matters in the Ohloh API at this point ... we're not dealing with bank transactions here ... if I see something show up twice in a paged Ohloh widget, I doubt I'll flip out about it. Opening up the code parsers and recognizing more code and comment types would get my vote as a better place to spend development energy. [Less]

I enthusiastically second this; Scala is transitioning from interesting to important. My company is doing real work in it now, and would love to see it added both as a choice and as a code type ... [More] (.scala) for metrics. We will be happy to participate in the open source language parser project for Ohloh! [Less]