Meta changes notification will be useful
Open, LowPublic

Description

Author: mwbugzilla

Description:
The meta info is treasure for a well-written bot. The problem is, fetching it on every login is bandwidth waste, and relying on an obsolete cached copy might produce bad results.

Is it possible to create a way to check if (and what) meta info has changed?

The best idea I came with is a request that will supply the "last fetched here" timestamp and will get a description of what meta should be re-requested. For example, the description may list the meta types and their parameters that should be requested. Then, the bot may request them if / when needed for its task.

(I came to this idea while trying to write a new version of Apibot.)

Grigor Gatchev


Version: unspecified
Severity: enhancement

Details

Reference
bz39061
bzimport raised the priority of this task from to Low.
bzimport set Reference to bz39061.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Aug 5 2012, 9:22 PM

Did you mean meta=siteinfo?

mwbugzilla wrote:

Also meta=allmessages, meta=userinfo (where affected by the site change), meta=globaluserinfo (where affected) and possibly other meta (eg. when a new meta param is introduced.

Paraminfo changes will be very useful, too - forgot about them in the first post. In short, any info a bot will better depend on, and is reasonable to cache it.

Anomie added a subscriber: Anomie.Feb 19 2015, 8:53 PM

MediaWiki itself doesn't know when this "meta" information changed, since much of it comes from various configuration variables, so the timestamp-based scheme described here has no hope of working.

If someone wanted to do this, they'd probably want to base it on hashes of the data rather than timestamps. Something as simple as md5( serialize( $data ) ) should be sufficient. To avoid doubling the work on the servers (constructing the result once to be hashed and then again when the client finds a hash mismatch and re-requests) and an extra round-trip for the client, the ideal behavior would be for the client to submit its hashes along with the data-request and the API return both the data and the new hash on mismatch.

Anomie moved this task from Unsorted to Needs Code on the MediaWiki-API board.Feb 19 2015, 8:53 PM

Would also be nice to support "If-Modified-Since" or "If-None-Match"—depending on the cache control mechanism used.

Anomie added a comment.Jun 1 2015, 9:58 PM

"If-Modified-Since" is timestamp based, which I explained above isn't
likely to happen here.

"If-None-Match" seems less expressive than what's requested here, but might
be doable.