16 Commits (737ea2f2af1c3174354e7c5af20d0ddda7ac3286)

Author	SHA1	Message	Date
Jordan Orelli	737ea2f2af	prevent duplicate uploads	3 years ago
Jordan Orelli	49a3a47e1d	upload not working yet	3 years ago
Jordan Orelli	993982441c	remove dead code, handle errors better	3 years ago
Jordan Orelli	1a04bde6ef	can serve the mod file endpoint now	3 years ago
Jordan Orelli	f1ee16b319	serve zip files	3 years ago
Jordan Orelli	4462b61a08	add info endpoint	3 years ago
Jordan Orelli	1a753ca5e5	add @latest endpoint	3 years ago
Jordan Orelli	01cd3216c5	some cleanup	3 years ago
Jordan Orelli	0087101de9	ok, stepping into an actual structure now ... proved that I could manage the protocol with something that was faked, starting to try to serve something for real. The idea is that you would have a directory that contains all of your module zips, and the mir server would serve modules from that directory, and it would query that directory to find out which versions were available and which were latest. I'm not sure about the version list and retractions. It seems like if a module is retracted you still want it to be in the list of available modules, and that a retraction is not signaled by the absence of that version in the list endpoint, but by the module file of the latest version itself. /srv/mir └── modules └── orel.li └── mir@v0.0.0-pre1.zip	3 years ago
Jordan Orelli	9d454a752e	right more renaming stuff	3 years ago
Jordan Orelli	1e569c08cd	mir, perhaps, is this project's name	3 years ago
Jordan Orelli	095a769a5e	sure why not	3 years ago
Jordan Orelli	2a8097a6f0	start putting index in a file	3 years ago
Jordan Orelli	a2bdee608c	some junk	3 years ago
Jordan Orelli	daa904b591	figured out how to serve something w00t	3 years ago
Jordan Orelli	dbeba4fa94	switching computers	3 years ago