Rewrite project based on lessons learned

[Und3rf10w]

As much as I hate to do this, at this point, I'm strongly leaning towards a total rewrite of this project based on lessons learned thus far. I believe I can architect a much more sane design that can easily support recovery of sessions, simple and understandable threading, record keeping, straightforward api implementation, and simplify the process to add new features.

Here is a diagram I created that outlines my vision for what a rewrite would look like:

[Und3rf10w]

See the above referenced issues for additional context and insight into challenges with the current implementation that this redesign aims to mitigate.

[Und3rf10w]

A rewrite should also attempt to better comply with PEP8. At a minimum, a rewrite should comply with the following objectives (taken mostly from PEP8):

• All indentation will be 4 spaces per indentation level.
• Surround top-level function and class definitions with two blank lines.
• Method definitions inside a class are to be surrounded by a single blank line.
• Imports should be grouped in the following order, with a blank line between each group of imports:
  1. standard library imports
  2. related third party imports
  3. local application/library specific imports
• Module names are to have short, all lowercase names. Underscores should be avoided when possible.
• Class names are to have CamelCase names. Underscores are to be avoided in this case.
• Exceptions are to follow the class naming convention, and are generally to be suffixed with Error
• Variable and function names are to be lowercase_with_underscores
• Constants are to be CAPITALIZED.
• Opt to include docstrings where useful and/or relevant. Ideally, each class, function, and method would contain a docstring.

If the rewrite successfully follows this standard, a CONTRIBUTING.md guide will be created and the above will used as a styleguide.

[Und3rf10w]

Opened new branch rewrite, will use that to track progress of rebuild.

[ghost]

Are you looking for any contributors to help? I'd be happy to help you get this ball rolling. @Und3rf10w

[Und3rf10w]

@realoriginal I promise I'm not ignoring this; honestly, I'm somewhat struggling with what I want the final result to look like and how to best approach it. At this time, I'm not quite yet ready to get started the actual implementation of the rewrite, but would sincerely appreciate any input on it. Once the actual vision gets solidified, I would LOVE to have contributors to that goal! I'm purposely trying to avoid writing code then revisiting it later in the rewrite, but have the obvious risk of feature creep. Classic example of second system effect :)

Short of input on the rewrite (for now), I would love any contributions to the dev branch that attempts to fix #13 (no clue how to best tackle this, but some ideas documented in the issue), and/or #14 (ideally a solution that doesn't rely on writing "state" files for each session or using a database, as I'm not particularly yet concerned about tracking sessions between server executions). Once these issues are resolved, that would bring the dev branch to a state where it is ready to be merged into master and released as the beta version. At that point, I'd like to either get started on the rewrite, or see some usability enhancements; such an easier to use builder, perhaps a simple console interface akin to GreatSCT or Veil.

[ghost]

No worries mate, I'll give it a look over, apologies for slow reply and ill pr a few things @Und3rf10w