I figure that getting a negative or 0 delay time will be due to signal latency. By the time you hear the message about when to retry, it's already ok to retry right away. But I can throw in a minimum time. What should it be?

Can you clarify this annotation?

Can you clarify this annotation?

Can you clarify this annotation?

I don't think we need a minimal delay if the server tells us to retry right away. We just need to make sure the caller interprets that as a "retry needed now" answer rather than a "go ahead and process" as it seems to be now

If the repo_type/repo_url abstract methods are replaced by one that just returns the swh.storage-compatible origin dict, then this origin_dict method is not needed anymore.

If the repo_type/repo_url abstract methods are replaced by one that just returns the swh.storage-compatible origin dict, then this task_dict method should be fed that dict directly.

I don't think the within_bounds debug statement is needed?

Can we haz something more meaningful as doc here, e.g., a description of what abstract attributes are usually used for in the context of SWH listers.

A brief description of what a "lister" in SWH context would be nice here. It's something that we are going to need to write anyhow as conceptual basis for presenting the API people will need to implement to realize a new lister. I guess it could go here. One short paragraph might be enough.

Additionally though, we need here developer-oriented documentation explaining what subclass implementors should implement to realize the various functionalities of a lister (e.g., full v. incremental listing).

So, it bothers me a little bit that this HTTP-specific part is in the base lister. Conceptually, to me, the lister should be agnostic w.r.t. the protocol used to list remote forges. We're already taking a big step here, so I don't think this should be blocking anything, but how critical is having this code here? And what would be the alternatives?

For instance, would moving this (plus everything HTTP specific) to a new HttpAPISwhLister sub-class, that would be uses as base for implementing all listers of forges that do use an HTTP-based API make sense? Or would it be overkill?

This module looks like a good place where to briefly describe the different listing "discplines" we support, one per task.

This makes me realize that the copyright years throughout your refactoring should be the range 2015-2017 in most cases (except for code you wrote from scratch).

Can we pretty-print this, e.g. using json-glib-format from json-glib-tools, and possibly rename the file to a .json extension?
Same for api_empty_response.txt (previous hunk)

minor numbering issue here :)

This is still pending — as shown by the TODO marked right below this hunk — right?

Do you prefer to merge leaving that pending or what?

as above, please rename this to .json

ditto, please rename to .json, but otherwise this one is already pretty-printed, yay! :)

Into reformatting, but if I name it .json it will also need another variable pointing at the filename instead of using the same one everywhere.

I don't _want_ to leave it pending. I just don't have a good description of tasks to put in there. :)