EnterpriseChoob

Choob needs to be more Enterprise. Enterprise projects have Tests.

Tests

• Mocking IRC is easy. Providing an integration-testable IRC is probably terrible.
• Mocking MySQL is utterly impossible. Providing an integration-testable MySQL is terrible.

The solution? Mocked IRC + database agnosticism, from a different ORM.

Other wants

• The ability to start the bot without any set-up or provided resources (i.e., the ability to run against an empty sqlite database).
• A security model someone understands and cares about
• Perhaps use something modern to do plugins, instead of doing it by hand? DI?
• No JJTree code anywhere near anything ever again

What does this involve?

• Replace ObjectDB with Hibernate. Sounds easy, but:
  • ODBQL is slightly, but not significantly, different to HQL.
  • Security.
    • ObjectDB uses inspection to work out that a plugin isn't trying to query something it shouldn't see.
    • Hibernate has sessions, but they need to be tied to something (i.e. they need to be done at the plugin manager level), and they need the context classloader set (afaics; this is basically massive doom).
  • This is guaranteed to break any untested plugins
• Consider alternatives to the security model
  • This helps with the hibernate implementation
  • mullet has proposed all plugins running in the same, safe-superset context, i.e. do anything except fiddle with bot internals or the filesystem or.. etc., but isn't entirely sure; how neat can we get:
    • The majority of plugins should require minimal (no?) security configuration; i.e. no reason to restrict anything for social reasons, only for integrity,
    • Plugins being able to declare that they need specific permissions, and this being okay based on who's loading them (and for this to be simpler than listing /everything/, i.e. groups: HitsArbitraryUrls, UsesDbDirectly, ExecutesArbitaryUnsafeStuff, ...?),
    • Lots of UI work to make !Security not horrid,
    • ..without breaking the user's reasonable understanding of what's going on currently?
  • The debugger hacks break security; unclean
• Consider alternatives to the plugin loading, i.e. Spring or another DI framework; probably whichever can meet our horrible requirements:
  • This makes security models and Hibernate much, much scarier.. unless Spring can be made to understand security, and our "session" concept (a single irc command and it's repsonse)?
    • Currently a plugin is (kind of) in a classloader, and, in Enterprise, there's a static Map of Class<> -> Hibernate implementation details for ODB. Security is checked by the "classloader box".
    • Under Spring, we'd have to have... uh...
      • One Spring context per plugin
      • The freshly compiled class available to said context via whatever classloader is necessary
      • Whatever is necessary to make Spring autowire the constructor of the class like the current system
      • Copies of all of the dependencies we're allowing the plugin to ask for, via. the security classloader(?)
      • Dependencies aware of their injectability(?)
      • All the hibernate state half inside the classloader, and half outside the classloader; accessible by Spring but with access to the outside world..?
      • i.e. I have no idea how much of this can be solved without Spring having to be made aware of the classloader, noting that getting Spring to operate fully within, or fully outside, the classloader is Hard, and getting Spring to have half of it's beans run outside of the security manager is probably not easy.

What's happening?

The https://github.com/UWCS/choob/commits/enterprise branch has enough of an implementation of tests to see what a test would look like, but:

• It doesn't start
• There's a load of work to add a new plugin to the test framework
• It's full of horrendous hacks
• There's one hibernate Session per entity, as apposed to per plugin. It's convenient, but it breaks, at least in theory
  • Everything. Can't join, can't get hibernate to do joins
  • My brain, i.e. the design of the code

What to do?

• Come up with a better order for the following actions (may be easier with hindsight)
• (?) Rephrase the plugins to use the compatible subset of ODBQL and HQL
• Try and decide if we like the idea of simplifying the security model, and to get any other / related plugin-loading stuff cleaned up at the same time
• Work out where in the plugin-manager stack it makes the most sense to manage the hibernate context
• Work out how Hibernate works with security manager(s?)
• Make any changes to the ODB API necessary to map it over the hibernate one
• WRITE ALL THE TESTS
• Work out how to make the test framework flexible to plugins that require significant set-up or hit other non-immediate-reply-in-the-same-channel issues, i.e. basically anything unpipable. (!in, !nickcolour, !firstseen, etc.)
• Look at getting JPA-style features into plugins