MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Troubleshooting",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "24": {
                "pageid": 24,
                "ns": 0,
                "title": "Technical FAQ",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "= Technical FAQ =\n\nThis FAQ is targetted at developers or technical people that want to know more about what's going on under the hood.\n\n== IVSHMEM/Shared RAM ==\n\n=== What exactly is the IVSHMEM device? ===\nThis is a virtual device that maps a segment of shared memory into the guest via a BAR (Base Address Register). It also has additional features such as interrupt triggering for synchronization however we do not use these.\n\n=== What is the IVSHMEM device being used for? ===\nOne might assume that we are simply using the device for the captured frames, this, however, is not entirely accurate. Looking Glass also needs to capture mouse shape changes (the mouse cursor), and mouse movement events and feed these back to the client to render. We need this additional information as we actually are rendering the cursor on the client-side, independent of the frame capture. This is why when you move your cursor around it doesn't affect the UPS, which is only counting frame updates.\n\n=== Why do you need the mouse positional information? ===\nWindows has no notion of an absolute pointing device unless you are using a tablet, which does work, however, if you also want relative input for applications/games that require cursor capture, you need a relative input device such as a PS/2 mouse.\n\nThe problem is, due to the design of QEMU or the Windows mouse subsystem (not sure which), when the VM has both devices attached (which is the default for libvirt), mouse click events are always at the last location of the absolute positional device (tablet) even if the cursor has been moved with the relative input device.\n\nBecause of this bug, we need to always operate in relative mouse input mode, and since factors like windows mouse acceleration, or cursor movement by a user application may occur in the guest, we need to pass this information back so the client can render the cursor in the correct location.\n\n=== Why does LG poll for updates instead of using interrupts? ===\n\nInitially, we were using interrupts in early designs however it became clear that the performance, especially for high update rate mice was extremely poor. This may have improved in recent QEMU versions and perhaps should be re-evaluated at some point."
                    }
                ]
            },
            "165": {
                "pageid": 165,
                "ns": 0,
                "title": "Track-down a regression (git bisect)",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "== WIP ==\n\n\nIf you find a bug with a newer build of Looking-Glass that didn't exist with an older version, it may help the developers to know exactly which commit caused the bug. Git bisect can speed up finding the commit that caused the bug."
                    }
                ]
            }
        }
    }
}