Compare commits
No commits in common. "d466ab6d131caacc6861db3a68841c97f12979fc" and "75ffdfdc278d0f805cb9737719811970018778c6" have entirely different histories.
d466ab6d13
...
75ffdfdc27
2
Makefile
2
Makefile
|
@ -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
|
||||||
|
|
|
@ -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).
|
|
||||||
|
|
67
roadmap.md
67
roadmap.md
|
@ -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.
|
|
Loading…
Reference in New Issue