Skip to content
This repository has been archived by the owner on Sep 2, 2021. It is now read-only.

Web interface and REST API #1

Open
gdude2002 opened this issue Nov 21, 2013 · 9 comments
Open

Web interface and REST API #1

gdude2002 opened this issue Nov 21, 2013 · 9 comments
Assignees

Comments

@gdude2002
Copy link
Member

gdude2002 commented Nov 21, 2013

Recreating this issue


More of a note myself, this will use the awesome Bottle framework and CherryPy HTTP stack.

The way Twisted handles this kind of thing is.. twisted.. and well, doesn't suit plugin compatibility at all, so we're going to have to use something which supports routing and other convenient functions - which Bottle does - and is fast - which CherryPy certainly is.

I'll be handling this, but anything that we think may be required should be commented below.

gdude2002 pushed a commit that referenced this issue Nov 22, 2013
Update fork with commits from main repo, to prepare for merge
@gdude2002
Copy link
Member Author

This is doing really, really well. Latest push as of this comment adds the beginnings of an API and an admin interface. Looking sweet!

@gdude2002
Copy link
Member Author

A lot of progress has been made on the web interface lately. Admin interface allows you to view config and data files - as well as edit and save data files, which are reloaded automatically.

Thus, plugins that have registered reload() callbacks for their data files really play nicely with this. Editing of config files is also coming!

@gdude2002
Copy link
Member Author

Config files can be saved now. All works pretty much as expected. There's a few more things to look into, though.

  • Work out why Web reloads itself when we edit settings.yml
  • Work on the admin interface
    • Allow full plugin and protocol management
    • Allow package management
    • Allow explicit user management
  • Think about some kind of log viewer or chat page or something?
  • Write the JSON-based API
    • Create an API-key based authentication system
    • Tie API keys to login users and use their permissions
    • Allow users to create and manage their API keys
    • Add both protocol-agnostic and protocol-specific API methods
  • After the above is done, it may be time to rewrite the plugin. It's pretty messy.

@gdude2002 gdude2002 self-assigned this May 20, 2014
@gdude2002
Copy link
Member Author

Graphs? Graphs. Graaaaaaphs..

More to come!

@gdude2002
Copy link
Member Author

Working on the redesign.

EDIT: There's no scrollbar at the bottom of the menu, ignore that. :3


A few suggestions have been gained from @Zarthus

  • More stats on the main admin page - commands run, words said, etc.
  • Two additions to the file editor
    • Ability for files to provide a description
    • Ability to check the file parses correctly without actually submitting it
  • A "reset" button on the login form that provides a customizable message written in Markdown

@gdude2002
Copy link
Member Author

Blocked by #14

@gdude2002
Copy link
Member Author

No longer blocked, #14 is done.

@gdude2002
Copy link
Member Author

Here's some screenshots!

Admin overview

Example file (Blacklisted passwords)

Accounts page

@gdude2002
Copy link
Member Author

Now that I've sorted out my API stuff for this plugin, let's see what we might do for routes.

API routes 2 electric boogaloo examples edition

  • /api/v1/[key]
    • /manage - This is for management, eg loading/unloading/info
      • /plugins
        • [GET] List plugins
        • /[action] (Params: {"protocol": "[plugin-name]"})
          • [GET/POST/PUT/DELETE] Do the thing
      • /protocols
        • [GET] List protocols
        • /[name] (Params: {"protocol": "[protocol-name]"})
          • [GET/POST/PUT/DELETE] Do the thing
    • /core - This is for core protocol actions (generic stuff, eg sending messages)
      • /protocols
        • /[name]
          • /[action]
            • [GET/POST/PUT/DELETE] Do the thing
    • /ws - Websockets!
      • /[socket_name] - (Haven't decided on this yet, need to look into how ws/etc works)
    • /plugins - This is for api calls registered by plugins (separately, not generic stuff)
      • /[name]
        • /[action]
          • [GET/POST/PUT/DELETE] Do the thing
    • /protocols - This is for api calls registered by protocols (separately, not generic stuff)
      • /[name]
        • /[action]
          • [GET/POST/PUT/DELETE] Do the thing

  • [POST] /api/v1/[key]/manage/protocols/shutdown (Params: {"protocol": "irc-esper"}) - Shut down the irc-esper protocol
  • [POST] /api/v1/[key]/manage/protocols/reload (Params: {"protocol": "irc-stormbit"}) - Reload the irc-stormbit protocol
  • [POST] /api/v1/[key]/manage/plugins/reload (Params: {"plugin": "URLs"}) - Reload the URLs plugin
  • [GET] /api/v1/[key]/manage/plugins - List all plugins and whether they're loaded or unloaded
  • [GET] /api/v1/[key]/manage/protocols - List all configured protocols and their statuses

  • [POST] /api/v1/[key]/core/protocols/irc-esper/send_msg - Send a message to a channel or user on the irc-esper protocol
  • [POST] /api/v1/[key]/core/protocols/irc-stormbit/join_channel - Join a channel on the irc-stormbit protocol

  • [???] /api/v1/[key]/ws/[socket-name] - Not sure yet, probably going to use these to stream various types of events

  • [GET] /api/v1/[key]/plugins/factoids/get - Get the contents of a factoid
  • [POST] /api/v1/[key]/plugins/factoids/set - Create or replace a factoid
  • [PUT] /api/v1/[key]/plugins/factoids/append - Add a line to a factoid
  • [DELETE] /api/v1/[key]/plugins/factoids/delete - Delete a factoid

  • [POST] /api/v1/[key]/protocols/irc-esper/mode - Set a mode on a channel on the irc-esper protocol
  • [POST] /api/v1/[key]/protocols/mumble/set_permissions - Set some permissions on a channel on the mumble protocol

Any thoughts on this layout, @rakiru?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants