Started roadmap.md
							parent
							
								
									8bff21b346
								
							
						
					
					
						commit
						c8a06f7af9
					
				|  | @ -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). | ||||
|  |  | |||
|  | @ -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. | ||||
		Loading…
	
		Reference in New Issue