Proposal for connection refactoring and user tracking

[dmptrluke]

Draft Proposal for Connection Refactoring and User Tracking

Okay, here we go

Firstly, I don't really like the separate client base class. It's not really needed since we pretty much gave up on support for multiple protocols.

I want to split up the irc package into a number of files for different functions, as detailed below:

irc>
    client.py - contains the Client class whichs owns a Protocol and a Tracker
    - protocol.py - has the IRCProtocol class
    - tracker.py - has the new Tracker class

    state.py - contains classes like User and Channel for other classes to use
    message.py - not entirely sure if we want to use this, but it's a class that abstracts IRC messages.   
                           Maybe we should combine this and state.py into models.py

The Beginning

My proposal for handling a received message is as follows:

• IRCProtocol recieves a message, uses the Message class to parse it and passes on the Message to the Client.
• The client then passes the Message to Tracker, waits for Tracker to finish working.
• The tracker will return a User object representing the user who was tracked.
• The client then creates an Event using the Message and User
• The Event is executed using bot.process() as usual

(the reason for the separation is because we want to avoid the complexities and overhead of plugin execution for the tracker)

After this:

• The tracker does tracking (detailed below)
• and the bot continues the rest of the plugin execution as it did before

Introducing the Tracker Class

The tracker class is in charge of tracking users on IRC. It receives a Message with tracker.track() and will have functions for getting info on users.

Why is this not just part of the Client?

I decided to make this class separate to stop the Client code from getting too cluttered with extra stuff, mostly. One of the side goals of this proposal is to separate the IRC components into more logical blocks.

Why is this not just a plugin?

I don't want to make this a plugin because it needs to execute before all other plugins, and I want it to be accessable with the tracker arg in plugins, or conn.tracker.

What does Tracker listen for?

Tracker will listen for WHO replies, WHOIS replies, JOIN and PART commands, etc, and process them accordingly.

I have plans for this to be detailed soon. TBC

How will plugin developers use it?

Much like plugins can currently use chan and nick, they will be able to use user and channel. They can also access conn.tracker directly if they want to interface with it

Requesting feedback @daboross

[dmptrluke]

I'm thinking of perhaps not having Message be a class that parses IRC mesages, and just having it be what tracker.track() returns. Makes more sense, maybe.