Compare commits

..

No commits in common. "d466ab6d131caacc6861db3a68841c97f12979fc" and "75ffdfdc278d0f805cb9737719811970018778c6" have entirely different histories.

3 changed files with 1 additions and 72 deletions

View File

@ -11,7 +11,7 @@ release:
.PHONY: release .PHONY: release
push: push:
@ ./build -m rel -a push @ ./build -m prod -a push
.PHONY: push .PHONY: push
# Run # Run

View File

@ -20,7 +20,3 @@ Each module contains the following base files:
module directory if need be. module directory if need be.
Every module has a `routes` function that returns its route macros. Every module has a `routes` function that returns its route macros.
## Roadmap
See [roadmap.md](roadmap.md).

View File

@ -1,67 +0,0 @@
# 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.