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!
@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
using the latest version of lwip, the images don't have an alpha channel anymore
apparently before @94322f3 npm thought 'crafatar/lwip' means git tag v0.0.5
and after that commit, using 'EyalAr/lwip' it noticed there's a v0.0.6
...
...
...
wat.
from the 'request' docs:
encoding: Encoding to be used on setEncoding of response data. If null, the body is returned as a Buffer. Anything else (including the default value of undefined) will be passed as the encoding parameter to toString() (meaning this is effectively utf8 by default).
unfortunately we can't use stream pipes because we need to generate
a hash of the content for the Etag.
I think proper caching (i.e. Etag) is very important
when using cache.save_hash, an `undefined` skin or cape hash means "do not touch"
while `null` means "overwrite as non-existent"
this was sent to redis after calling /capes/Notch for the first time:
"hmset" "notch" "c" "3f688e0e699b3d9fe448b5bb50a3a288f9c589762b3dae8308842122dcb81" "t" "1429651244222"
"hmset" "notch" "s" "a116e69a845e227f7ca1fdde8c357c8c821ebd4ba619382ea4a1f87d4ae94" "c" "" "t" "1429651244235"
as you can see, the first request stores the c(ape) but does not touch the s(kin), whereas the second request
sets the s(kin) and replaces the c(ape) value
jomo