Class OparlClient

The bodies (Körperschaften) of a System — usually one per municipality.

Known OParl endpoints: the public registry at dev.oparl.org merged with the curated list (source "all", the default), or either one alone. The registry is a snapshot that is rarely updated; the live checks shipped with this package decide what an entry reports (working, checked, problem, replacedBy, note and the System data). Curated entries follow the registry's. A System listed twice appears once — under the registry's entry where both lists hold it, reporting whichever of the two live checks is newer. source "curated" makes no request.

Fetch one OParl object by URL. Rejects non-objects and OParl/vendor error objects ({ "type": ".../Error", "message": "…" }, { "error": "…" }) with an OparlParseError.

Walk one of a Body's object lists (meetings, papers, persons, …). Filters are passed to the server as OParl query parameters; servers are required to support the date filters, but in practice some ignore them.

A Body without a legislativeTermList URL (every OParl 1.0 body) embeds its terms in legislativeTerm; those are returned as they are (pages: 0, nothing fetched), with the date filters applied locally. A term the server left without the mandatory created/modified cannot be excluded by a date filter, so it is kept and the result's note says how many terms the filter could not be applied to.

Fetch one list page and check it has a data array of objects. A server that answers a list URL with a bare JSON array instead of a list page (seen on an SD.NET RIM build in Essen) is read as a single page holding those objects.

Fetch a System, the entry point of an OParl server.

Walk a list from its first page along links.next, staying on the same host. maxPages 0 fetches every page. The query (filters) is set on every page, including on the server's next links (see carryQuery), and on the next returned.

Objects are listed once per id; when a page repeats an id, the later copy wins, since that is the newer one — a list that changes while it is being walked serves the edited object, or the spec's deleted: true tombstone, on the later page.

The walk gives up early — looped: true plus a note saying why — when the server's next points back at a page already fetched, or when MAX_UNPRODUCTIVE_PAGES pages in a row add no object that wasn't already listed (some servers serve the same page, or an empty one, under ever-new ?page=n links). The next of the last page fetched is still returned in that case, so the walk can be resumed by hand. A next this client refuses to follow (another host, not http) also ends the walk with a note, keeping the pages already fetched.