MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Rob_Mayoff",
        "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": {
            "2070": {
                "pageid": 2070,
                "ns": 0,
                "title": "Roadmap",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "'''AOLserver 2005 Roadmap'''\n\n[[Jim Davidson]] has offered the following summary [http://listserv.aol.com/cgi-bin/wa?A2=ind0506&L=aolserver&P=6872] based on the ChangeLog that describes the changes going into AOLserver 4.5:\n\nWe should put a page on aolserver.com with some details.  We've moved\nthe version to 4.5 from 4.1 to reflect the scope of changes.\nScanning the ChangeLog and from what I can recall:\n* New connection management features including the ns_limits and\nns_pools commands:\n\n-- ns_limits: control # of threads executing and/or waiting for\nexecution by method/URL\n\n-- ns_pools: map method/URL's to specific thread pools\n\nThe idea is to use the two together, e.g., map slow-running db\nrequests to specific pools and set limits to avoid overload. The\nresult would be to trap cases where impatient folks press reload when\nthings are slow, generating quick \"try later\" responses instead of\ngumming up the server.\n* I/O features including:\n\n-- A new \"Ns_QueueWait\" API to enable event-driven callbacks in the\ndriver thread before dispatching to pools for processing.  The model\nis to augment data received from the client (headers, request,\ncontent) with additional data fetched over the network (likely stored\nin the new Ns_Cls \"connection local storage\" API's) before\ndispatching to the connection threads. An example would be to add\ncertain personalization data received via a web service. The\nrationale here is that I/O events are cheap so do those upfront\ninstead of having expensive connection threads burdened with wasteful\nblocking I/O.  This is a somewhat obscure and technical interface.\n\n-- Ability to manage larger file uploads by spooling to a temp file.\nThis keeps many of the useful functions folks utilize from working\nfor these large files, in particular auto-parsing of input available\nvia ns_conn form, but is available for custom apps willing to deal\nwith the complexity.\n* ADP improvements including:\n\n-- A new execution caching technique at the ns_adp_include level\nwhich allows you to save the results of execution of an included ADP\n(and includes below that) for reuse on subsequent connections up to a\nspecified time.  Embedded ns_adp_include's with the -nocache flag at\nlower levels allow you to still execute dynamic code within cached\nblocks if necessary.  The goal is to improve performance of pages\nwhich are nearly dynamic, i.e., pages where underlying data really\nisn't personalized but instead may change every few minutes or so.\nWe prototyped this technique at AOL for an app which had these\ncharacteristics and drove transaction throughput from less than 50/\nsecond to well over 400 while still maintaining certain personalized\nfeatures of the page.\n\n-- New \"singlescript\" config option which turns ADP pages into a\nsingle script enabling syntax such as \"<% foreach e $list { %>\nelement <%= $e %> here <% } %>\" and treating an error anywhere on the\npages as an error for the full page.  Evidently this is more similar\nto other execution environments such as JSP.  It's a matter of\nopinion whether this is a better or worse approach to ADP execution -\nthe default is off.\n* Output buffer improvements via new Ns_ConnFlush:\n\n-- Automatic UTF-8 to output charset encoding\n\n-- Gzip compression\n\n-- Streaming output in chunked-encoding format instead of the\nprevious \"response with no length\" HTTP/1.0 method.\n\nMuch of the code for Ns_ConnFlush was previously private to ADP.  ADP\nhas been modified to use Ns_ConnFlush and will also automatically\nswitch into streaming mode when output buffer limits are exceeded\n(the previous behavior is to simply keep buffering without limit).\nNs_ConnFlush could be useful to simplify and standardize output from\nother execution environments as well, e.g., PHP and Java servlets.\n* Tcl improvements including:\n\n-- Cleaned up and well commented core code so folks can understand\nthe arcane config/resource management approach of Tcl within AOLserver.\n\n-- A new Ns_TclRegisterTrace API to enable callbacks at key state\ntransition points in a much more natural way.  The ns_ictl command\nhas been updated to support script-level traces.\n* A new Ns_Task API designed to replace the old Ns_SockCallback API\nwhich didn't do a very good job at managing timeouts along with I/O\nevents.  The ns_http command has been modified to use Ns_Task (the\nold Ns_SockCallback-based ns_http is also still available via\nconfiguration for the paranoid).\n* Numerous bug fixes.\n\n\nUnfortunately, no comprehensive list is maintained of these changes\nand the documentation is not yet up to date.  Actually, the\ndocumentation hasn't been up to date since version 2.3 which is a\ngreat disappointment for me.  However, the ChangeLog has been\nmaintained quite well so it's possible to get an overview of the\nvarious bug fixes and other minor updates from there.\n\nDossy and Zoran may recall other new features as they've been active\non the release as well.  Overall, I believe we're done with 4.5 and\nshould tag it, complete the documentation, produce some quality\nrelease notes, and move on to 5.0.\n\n----\n\n'''AOLserver project 2004 Roadmap'''\n \nThis document will serve as the roadmap for the AOLserver project and Open Source community for 2004.\n \nN.B.:  There is no designation whether any of the tasks necessary to complete items on the roadmap must be performed by an AOL employee or someone from the larger AOLserver community.  Ideally, tasks will be completed by whoever is enthusiastic about the work, has the necessary time to commit to completing it as well as the capability.  There is no explicit limit to the amount of contribution that can come from any participant in the project.\n\n----\n\n'''Goals and milestones for Q3 2004'''\n\n'''1)  Feature roadmap for AOLserver through 2004 and into 2005'''\n\nIn order to enable the Open Source community to better participate, it is important that we have a clear list of [[Features]] that should be worked on.\n\n----\n \n'''Goals and milestones for Q2 2004'''\n \n'''1)  www.aolserver.com website revamp'''\n\nThe project website deserves a more modern look and feel while maintaining the crisp, clean design aspects of the site.  The site needs to clearly represent the most current releases and recent changes.\n\nSpecific information that should be easily accessible on the website initially:\n* what it is\n* how it's different\n* where is useful, where it's not\n* how to get started - basic guide, notes for apache users\n* latest source and binary bundles\n* basic intro docs and extensive, complete, accurate manpages\n\n''Update on 6/25: aolserver.org and aolserver.net should both point to aolserver.com by the week of 6/28.''\n\n----\n\n'''2)  Freshen up documentation'''\n\nCurrently available documentation for AOLserver mixes information for 2.3, 3.x and 4.x.  All of the documentation needs to be evaluated for correctness and updated where appropriate.  Documentation should be made available in at least three formats: plain text, HTML and PDF.  All documentation should be readily available from the project website.  \n\nThe goal is to have a list of all documentation, both what exists and what we still need, by 5/26.  From there, the plan is to spend the next 4 weeks verifying or updating documentation.  Targeting 6/25 to have documentation for AOLserver 4.0 complete.\n\n''Update on 6/25:  [[Tcl API]] effort: 142 out of 228 commands or 62% complete.  Work on the [[Tutorials]] and HOWTO sections have also begun.  See the [[Documentation]] page for more.''\n\n----\n\n'''3)  SourceForge bug and support trackers'''\n\nThere are currently 56 open bugs, 3 open support requests, 29 open patches and 8 open feature requests in SourceForge.  Attention to these trackers is minimal at best which sends the wrong message about the project's commitment to supporting itself.  \n\nThe current goal is to ensure that opened requests get assigned to someone within 24-48 hours and resolved in a reasonable timeframe.  Resolutions for common problems should be properly documented and published appropriately.\n\n''Update on 6/25:  78 open bugs, 4 open support tickets, 37 open patches, 14 open feature requests.''\n\n''Update on 7/2:  Bugs: 78 > 39 (-39 / -50%).  Support Requests: 4 > 2 (-2 / -50%).  Patches: 39 > 37 (-2 / -5%).  RFEs: 14 > 16 (+2 / +13%).  Current open bug breakdown by year: 2001 (7), 2002 (4), 2003 (20), 2004 (8).''\n\n''Update on 7/9:  Bugs: 39 > 66 (+27 / +41%).  Support Requests: 2 > 3 (+1 / 33%).  RFEs: 16 > 56 (+40 / +71%).  Current open bug breakdown: 2001 (8), 2002 (7), 2003 (24), 2004 (10).  The \"Patches\" tracker at SourceForge has been retired.''\n\n''Update on 7/16:  Bugs: 66 > 44 (-22 / -33%).  Support Requests: 2 > 2 (0 / NC).  RFEs: 56 > 40 (-16 / -28%).  Current open bug breakdown: 2001 (8), 2002 (5), 2003 (20), 2004 (11).''\n\n''Update on 7/23:  Bugs: 44 > 47 (+3 / 6%).  Support Requests: 2 > 2 (0 / NC).  RFEs: 40 > 41 (+1 / 2%).  Current open bug breakdown: 2001 (8), 2002 (5), 2003 (19), 2004 (15).''\n\n''Update on 9/1:  Bugs: 41.  Support Requests: 0.  Feature Requests: 49.  Current open bug breakdown: 2001 (7), 2002 (4), 2003 (13), 2004 (17).''\n\n----\n\n'''4)  Better release management of AOLserver'''\n\nWhile maintaining a ChangeLog and tagging code periodically may be suitable for the developer community, the larger user audience of AOLserver has a varying degree of technical background.  Releases need to be managed such that a clear communication accessible to a non-technical background should be able to understand the value contained in the latest code release providing clear and compelling reasons to keep their installations up to date.  This same information should also be be published on the project website as well as distributed to the AOLSERVER-ANNOUNCE mailing list.\n\nWe need to ensure that changes since the previous release will be collated and prepared along with the actual code release, then published on the wiki and the aolserver.com website.  Official releases will be published in source and binary form (when applicable) on the project website via the Project Files section in SourceForge.  An update to the AOLserver project record on Freshmeat.net should also be done.\n\n''Update on 7/16:  With the bug that slipped into the 4.0.6 release, it's obvious that even a simple automated test suite would prove useful.  With that, it's time to start documenting: [[How are releases tested]].''\n\nRelease announcements:\n* 07 Sep 2004: [http://listserv.aol.com/cgi-bin/wa?A2=ind0409&L=aolserver-announce&P=66 AOLserver 4.0.8]\n* 19 Jul 2004: [http://listserv.aol.com/cgi-bin/wa?A2=ind0407&L=aolserver-announce&P=163 AOLserver 4.0.7]\n* 16 Jul 2004: [http://listserv.aol.com/cgi-bin/wa?A2=ind0407&L=aolserver-announce&P=61 AOLserver 4.0.6]\n* 07 Jun 2004: [http://listserv.aol.com/cgi-bin/wa?A2=ind0406&L=aolserver&P=4884 AOLserver 4.0.5]\n* 26 Mar 2004: AOLserver 4.0.3\n* 23 Nov 2003: AOLserver 4.0.2\n* 20 Nov 2003: AOLserver 4.0.1\n* 03 Nov 2003: AOLserver 4.0.0\n\n----\n\n'''5)  Establish metrics for measuring success and publish reports on a regular basis'''\n\nThere are several simple measurements that we can take that can be automated on a regular schedule (daily, weekly, monthly) and published on the project website.  The first metric will be:\n\nCommit frequency per username: number of files affected, lines of code affected.\n\nThis serves the purpose of making clear to the community where activity is taking place within the project as well as which individuals are actively involved and participating.  Without this, it is unclear from a high level what kind of progress is being made on the project, if any at all, giving people a sense that the project is inactive when that may not actually be the case.  Having this metric measured regularly and published will either confirm or dispel this belief and allow us to better manage this issue.\n\n''Update on 7/9:  The first [http://article.gmane.org/gmane.comp.web.aolserver/10810 CVS commit stats for June 2004] were posted to the AOLserver mailing list.''\n\n''Update on 9/1:  CVS commit stats for [http://article.gmane.org/gmane.comp.web.aolserver/11299 July 2004] and [http://article.gmane.org/gmane.comp.web.aolserver/11300 August 2004] have been posted to the AOLserver mailing list.''\n\n----\n\n'''6)  Regular and open communications to the world'''\n\nIn order to raise awareness about AOLserver to both attract users and developers, we need regular and open communication with the world.  The messages need to be clear, concise and accessible to a wide audience.  They need to be sent out regularly to keep the attention of our audience as well as to show steady progress.    \n\n----\n\n'''7)  Tighter integration of Java into the core execution environment'''\n\nWith tighter Java integration into AOLserver, we will be able to leverage more available talent as well as more third-party developed software under AOLserver.  There are several efforts to bring Java into AOLserver but the project could benefit from having these separate efforts aligned and deliver a single solution.\n\nCurrently, the [[nsjk2]] module is under active development, especially at AOL, for supporting Java/Tomcat with AOLserver.\n\n----\n\n'''8)  Win32 platform becomes a first-class citizen again'''\n\nWhile even the more recent releases of AOLserver can still be built on Win32, the commitment of official support for it was left to the community to resolve.  Consider this the resolution: the audience for AOLserver on Win32 should not be diminished without good reason.\n\n''Update on 7/22:  The availability of [http://article.gmane.org/gmane.comp.web.aolserver/10927 experimental Win32 binaries] of AOLserver 4.0.7 was sent to the mailing list.  Links to downloads are on the [[Downloads]] page.''"
                    }
                ]
            },
            "1782": {
                "pageid": 1782,
                "ns": 0,
                "title": "Rob Crittenden",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "'''AOLserver [[Modules]]'''\n* [[nsnss]] -- SSL using Netscape portable runtime libraries.\n* [[nsdigest]] -- Access control lists for users/groups, supports digest authentication.\n\n----\n\n[[Category Home Page]]"
                    }
                ]
            }
        }
    }
}