HoodBot

Member since March, 2017
User-HoodBot-HoodBot.png

This is a bot run by RobinHood70. If at any time you notice the bot making inappropriate edits, please post a message on its talk page and the bot should stop what it's doing within a reasonably quick timeframe.

While development continues, this is now a fully functioning bot, and has largely replaced HotnBOThered apart from a few specific jobs.

Purpose of the BotEdit

The bot is multi-purpose, but is primarily geared towards information retrieval and page editing.

Bot TasksEdit

All editors are welcome to propose tasks that they think HoodBot could be used for. Please do so on the Bot Requests page, so that any bot owner can field a given request. Do not post on the bot's talk page, unless you intend to interrupt the bot's current job.
Current Task: None.

DesignEdit

The core of HoodBot is designed in traditional three-tier fashion, with each layer being responsible for different aspects of the bot. There are also numerous side projects and libraries. All layers are designed in C# (.NET Core 3.0), and the source code is publicly available on github. The three core layers are:

WallE is the Wiki Abstraction Layer for the bot (or, more generically, the data access layer). It allows higher layers to communicate with the wiki without regard to the underlying method of access (e.g., API, index.php/screen-scraping, or direct-to-database). The API module is currently the only developed method of access. It implements virtually the entire API in a version-agnostic manner (to the extent possible). It includes features such as time- and maxlag-based throttling, optional talk page checking with every request (inline with other requests, where possible) and, where the feature is available, assertion that it is logged in as the correct user at all times. Unlike HotnBOThered, it is also capable of checking that it is still logged in from a previous session, so does not need to log in/out for every job. Finally, the abstraction layer is extensible, meaning that custom wiki features can be added, such as loading MetaTemplate saved variables along with the regular page data.

Robby is the business layer. Its purpose is to organize the abstraction layer into more meaningful groupings, such as pages, page lists (e.g., categories or what links here), users, and general wiki functions like logging in or out, and uploading files. This layer is is now feature-complete, though it may need some tweaks as the high-level HoodBot layer is developed.

HoodBot is the presentation layer. This layer comprises the actual jobs themselves, along with a user interface to allow starting, pausing, or stopping any given job, and an estimate of when the job will be complete. Current or planned features of this layer include:

  • ☑Yes Pausing/cancelling jobs cooperatively, rather than relying on blunter task/breakpoint methods.
  • ☑Yes Job categorization and organization into multiple applicable folders (or hiding for those jobs that are not currently relevant but not yet retired).
  • ☑Yes Multiple simultaneous-but-independent reporting options including bot's results page, other pages, user talk page post, e-mail, or a local file. (In other words, the bot can drop results into a sandbox and then notify you by e-mail that it's done so.)
  • ☑Yes Merging multiple jobs/tasks into a single editing batch.
    Current status: The basic concepts are there, though it needs more development to really get it to the point that I'm envisioning.
  • ☑Yes Tasks that run as part of any other editing job if the page has already been changed anyway (e.g., to clean up links, remove/change undesirable formatting, remove hidden characters, etc.)
    Current status: Needs rethinking and development, both in terms of developing the actual tasks, and finding easy ways to integrate them.
  • ☑Yes Previewing diffs locally rather than relying on automating a browser to do it via the wiki.
    Current status: Currently automating Visual Studio to do the diffs for me, cuz it's easy and highly functional. Will be developing browser-based previews shortly as well, though finding software to do it seems to be a bit of a challenge. If nothing else, there's always good old IE, like HnB is using. At least that's automation-friendly.
  • ☑Yes Previewing every write action a job would take without it actually happening.
    Current status: Mostly developed, but needs a bit of polish.

...and probably more.

HistoryEdit

When I first designed HotnBOThered in 2010, I developed it using the DotNetWikiBot framework. At the time, it was the only truly general-purpose .NET-based bot framework I could find, and remains so to this day, but as time went on, I became increasingly disenchanted with it. Other frameworks exist, but are limited in their capabilities or are Wikipedia-specific...usually both. So, by 2012, I had started to toy around with developing my own framework. This went through several iterations that I wasn't terribly happy with until, around mid-2014, a post I stumbled on sparked the idea for a new, modular design concept that echoed the API itself. By Christmas of that year, I had decided that this concept was going to work out very well and started to work on WallE in earnest. Due to the magnitude and complexity of the API, and combined with the cognitive difficulties caused by my illness, it took over two years to finish that layer, but when I was done, I was quite happy with what I had produced, and continued on to develop Robby and HoodBot.

Unfortunately, though not unexpectedly, the project spanned several MediaWiki versions, and many early modules lack some of the features of their MediaWiki counterparts. Rather than spend more time on it, however, I decided that all the core functionality was there and that updating the modules to the latest version should not be a priority. At some point in the future, when I have the time and energy, I will select a fixed target version and update everything to that. If that happens, WallE will see a v2 in which all the code that targets deprecated/absent features prior to that version would be removed. This would not be a trivial project, however, as the API underwent some fairly substantive changes between versions 1.24–1.28, so it isn't (and shouldn't be) a priority.