Purpose of the Bot
The bot is multi-purpose, but is primarily geared towards information retrieval and page editing. It also has admin rights, so takes on a few admin-related tasks like page protection.
|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.
The core of HoodBot is designed in
old-school 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# 9/.NET Core 5.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). To the extent possible, it allows higher layers to communicate with the wiki in a version-agnostic manner, with the majority of API features that were available up to about MW 1.30. In theory, it could also allow communication without regard to the underlying method of access (e.g., API/index.php/mixed for read-only API), though only the API module is currently developed. It includes features such as time- and maxlag-based throttling, optional talk page checking with every nth 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. 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, what links here, page history), users, and general wiki functions like logging in/out and uploading files.
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:
- Pausing/cancelling jobs cooperatively, rather than relying on blunter task/breakpoint methods.
- Job categorization and organization into multiple applicable folders (or hiding for those jobs that are not currently relevant but not yet retired).
- 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.)
Current status: The basic concepts are there, though it needs more development to really get it to the point that I'm envisioning.
Merging multiple jobs/tasks into a single editing batch.
Current status: Needs rethinking and development, both in terms of developing the actual tasks, and finding easy ways to integrate them.
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: 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.
Previewing diffs locally rather than relying on automating a browser to do it via the wiki.
Current status: Mostly developed, but needs a bit of polish.
Previewing every write action a job would take without it actually happening.
...and probably more.
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.