Package system design and plan

Package system design and plan

The pitch

The Lounge's features will be split into packages, that can evolve, be managed and maintained independently. The Lounge will come with a set of pre-selected packages that can be disabled and can be extended with other official or third-party packages.

Advantages

• Ability to develop a feature that is not part of the official project
• Ability to test single features
• Ability to enable/disable features
• For official packages, ability to split responsibility across maintainers

A bare instance of The Lounge (without any packages) must be able to run essential IRC features. It can be used for testing (packages are run alone on this bare instance in a staging or CI environment) or for troubleshooting purposes. One can also test a package behavior with other specific packages by running a bare instance of The Lounge with selected packages.

API

Packages will want to interact with The Lounge through the following parts of The Lounge:

• Hook any message type from IRC
  • Read the entire message (all initial ones and any future ones), and replace parts of it
  • This would need to allow printing of unescaped html, to be fully useful (need to figure out how to do this safely)
• Hook any /command Details needed
• Notifications (Having notifications showing on browser screens can actually be a package...)
• Interact with configuration files
• Add items to the settings page
  • Types: checkbox, text
  • Allow us to get the value when it changes and set the default value
• Interact with the settings cookie
  • This should probably not be direct, but if we have a wrapper around it, then it's just "settings storage"
• ?

Key considerations before we can start implementing

• How to separate/deal with server vs client packages?!
• Who should be able to install/enable packages, user or administrator? If administrator, even for client-side packages?
• How to deal with packages clashing with each other? (Example: one package that for some reason disables all notifications and one package running one notification for all messages)
• How to extend package management so that themes are available using the same underlying mechanism?
• How much does the client need to be modularized to reach a first acceptable solution?

Package management

• Install them with npm
• Enable/Disable a package
• List all enabled/installed package

Package ideas

• Server-side
  • ?
• Client-side
  • Emojis
  • Markdown support (or else)
  • Upload multi-line messages to server or paste-service (like IRCCloud)

Deliverables

• API documentation
• Base package to help developers start their own package