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

Plan of action #1

@gdude2002

Description

@gdude2002

There are lots of things to do with this project. This ticket exists to help us plan and outline other tickets to work on separately.

  • Decide on a base framework -> Base framework #3
    • Twisted
    • Bottle
    • MongoDB (of course)
    • Yaml
  • Decide on a communications method between the managers and the site.
    • Site communication should probably be HTTP/JSON-based
    • Communication between managers may also suit this
  • Decide on a versioning method
    • Do we use git commits?
    • Do we allow devs to make a release from the latest repo state?
    • How do we handle upgrade steps?
    • How do we handle commit checking?
      • Should we make webhooks to use with GitHub?
        • Should we support non-GitHub repos?
  • Decide on documentation for packages
    • This will probably be markdown. How is it browsed?
    • How do we allow listing/searching of packages?
    • Should the site cache this stuff or should each repo manager provide a public API?
      • There are lots of advantages for the latter!
  • Decide on security and APIs -> Distributed hosting #2
    • Users login with GitHub, this is decided already
    • Do we allow users levels/teams for packages?
    • If we provide an API, how do we authenticate?
    • How do we authenticate managers?
      • How do we stop people adding managers randomly?

There are lots of other things to consider, but these are the things we need to answer first. And yes, we will be supporting multiple managers - we'll be able to split the load that way. See #2 for more on that.


Here's a list of aims to work with..

  • Right now, we use GitHub for storing packages. This feels hacky and has patchy uptime, with files randomly being served as GitHub 503 pages.
    • Provide a hosted service for authors to upload, manage and document their packages
    • Allow Ultros users to download, update and view packages from this service
    • Provide a private API that we can use to manage the hosted service
    • Provide a public API that Ultros bots, other applications and other sites can use for informational and data retrieval purposes
    • Produce the service in such a way that it scales easily
      • Provide a central control node/service that manages all hosted services
        • Provide a mechanism to securely add more hosted services to the network
        • Provide a method that uses the control node to display information and manage the hosted services via the site and API
        • Provide a control mechanism that can be used via the site, an Ultros bot or another API client
    • Ensure that all internal communication is secure and that malicious users (read: skids) can't tamper with the data

Metadata

Metadata

Assignees

Type

No type
No fields configured for issues without a type.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions