From c8a06f7af9e0b2e5bb2d98d42b86730d78b021ed Mon Sep 17 00:00:00 2001 From: Jef Roosens Date: Tue, 23 Mar 2021 13:47:57 +0100 Subject: [PATCH] Started roadmap.md --- README.md | 4 ++++ roadmap.md | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 71 insertions(+) create mode 100644 roadmap.md diff --git a/README.md b/README.md index d7dc9e6..bf60adc 100644 --- a/README.md +++ b/README.md @@ -19,3 +19,7 @@ Each module contains the following base files: module directory if need be. Every module has a `routes` function that returns its route macros. + +## Roadmap + +See [roadmap.md](roadmap.md). diff --git a/roadmap.md b/roadmap.md new file mode 100644 index 0000000..17b0d76 --- /dev/null +++ b/roadmap.md @@ -0,0 +1,67 @@ +# Roadmap + +This file contains a listing of my current ideas/plans for this project. This +could change at any minute, but it serves as a quick overview of my plans for +the project. + +## 1.0: Ivago + +### Summary + +* Base project structure +* RESTful wrapper around Ivago's API for showing the pickup calendar + +### Description + +Version 1.0 won't be a very big one, but it's important nonetheless. It +contains a base project, on which I can build all the other modules. The only +real feature it'll have is a wrapper around the Ivago API. + +Ivago is one of the companies in Belgium that comes pick up the trash. On their +site, you can view a calendar for your street displaying when they'll come pick +up which kinds of trash. The sad part is that this site is very much not a +RESTful API, relying on cookies to know which street & city you entered. + +In one of my Web Development classes, I was given the assignment to convert +this API into a RESTful one. I ended up fully wrapping it up using Python, so +my goal is to port said code to Rust so we can then query my API for the same +information their website would give. This allows us to remain anonymous while +still collecting the same data. Furthermore, having the data available in +computer-readable format opens up ways to write a custom frontend for the API +(which I will be doing sometime in the near future). + +## 2.0: The Curse of the Forge + +### Summary + +* Curseforge site scraper +* Easy lookup of download links for modpacks & their mods +* Caching of Ivago API + +### Description + +Let's start off by saying I'm an avid Minecraft players. I still play at least +once a week, even after almost 8 years of playing. I also love doing stuff on +servers, so combining this two is quite easy: I host lots of Minecraft servers. +These servers often run modpacks, to spice up the game. This is where the +motvation for this version comes in. + +The Curseforge website hosts *a lot* of modpacks, but sadly, they're not +exactly in a computer-friendly format. Furthermore, the "server files" zips you +often see included with a modpack just contain a yaml file, containing +definitions for mods that only their launcher can use. I'm stubborn however, +and refuse to use their launcher, as it doesn't work with my Docker-based setup +scripts, and I just like doing things myself. Therefore, I want to do the +following things: + +* Periodically scrape their site for all modpacks +* Store all the information I'll ever need in a database +* Provide endpoints that can return a list of mods to download & the config + directory + +I could then possibly integrate my API into my own scripts, allowing me to spin +up a modded Minecraft server from the command line, without having to ever +touch their websites or services (besides downloading the mods of course). + +As a bonus, I want to cache the Ivago API's calendars, considering I'll be +setting up a database for this version anyways.