https://bugzilla.wikimedia.org/show_bug.cgi?id=64508
--- Comment #2 from Thomas <[email protected]> --- I see no problem, with HTTP statuscode or api responses. I think the advantage of separation between header and request parameter is, that there is no mix between client and api abilities. My separation assumes that, the main goal of mediawiki api is to work with _wiki contents_ and lesser to handle server performance in hight traffic environments. Application Level : Do some magic with e.g. categories and its members API Level : map application data from/to something like json (uses params) select the endpoint urls for api requests Client Level : send the data to MW, handle gz compression, throttling (uses headers) encoding, applies user-agent, cookies, caching, ... If you have an existing application with these layers, and you want to add the maxlag ability, there I see the following posibilities: * API Level ** (3) change endpiont selection (create urls with maxlag) ** (2,3) handle maxlag responses from client level * Client Level ** (2) mutate endpoint urls from api level ** (1) add request header ** (1,2) handle maxlag The solution with the header field (1) wins for me, because it does'nt mutate the original request and breaks no layers between server performance and wiki data. Sorry, it's only an idea, so if you think, it's to exotic to give bots this additional possibility to separate server performance from working with content, feel free to close this with WONTFIX ``` function maxLag($params, $headers) { $paramMaxLag = $params["maxlag"]; $headersMaxLag = $headers["X-Accept-MediaWiki"]["maxlag"]; if (isset($paramMaxLag)) { return $paramMaxLag; } else if (isset($headersMaxLag)) { return $headersMaxLag; } else ... ``` -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
