this was originally implemented because we wanted to delete the oldest images on disk
where 'oldest' means not *used* for the longest time
that's not useful and was never actually implemented, so we don't need this
afaik you can have persistent storage on heroku, at least via addons
and heroku is probably not the only environment where one has a temporary file system
I think this makes more sense, especially when you run multiple instances
so they can use the same image cache instead of each version relying on their own
should be up to the user where to put log files
and to make sure that directory actually exists
currently nothing in this code base expects
logs/ to be present.
this will close the server, i.e. all new connections will be dropped
while existing connections are able to complete within 30 seconds
otherwise they are dropped and the server force quits
From the iojs docs:
> An unhandled exception means your application - and by extension io.js itself -
> is in an undefined state. Blindly resuming means anything could happen.
>
> Think of resuming as pulling the power cord when you are upgrading your system.
> Nine out of ten times nothing happens - but the 10th time, your system is bust.
>
> uncaughtException should be used to perform synchronous cleanup before shutting
> down the process. It is not safe to resume normal operation after
> uncaughtException. If you do use it, restart your application after every
> unhandled exception!
- we don't need to resize images. canvas can do that for us
- we don't need to use `scale(-1, 1)` to draw flipped
- most of the old/new skin format shares the same code
- we can draw the skin image directly on the canvas
@Jake0oo0 fyi
We haven't changed anything on our 3D renders since we first introduced them.
They still have rendering glitches, they still don't render the jacket layer,
they still don't support alex-type skins.
Telling people this is no longer beta (@2515575) doesn't seem like a good idea.
human_status (response.js) defines code -2 as 'user error'. 404 is definitely a user error, so using that makes sense.
eventually we should change the whole status code thing with #120
