5 ms·

If you look at their API you'll see that the token can be cached for up to a week. I doubt that having a check if the token is up to date will add much complexi

by d4l3k 10y ago

If you look at their API you'll see that the token can be cached for up to a week. I doubt that having a check if the token is up to date will add much complexity.

truetraveller 10y ago
It really does add complexity: -I have to store the cached token somewhere: -I have to do date arithmetic, what if my server clock is incorrect, -if an API call failed, I have to check for an additional error: a invalid token I don't mind complexity when it is needed, but I do not prefer complexity for no good reason. That being said, can it really be cached up to a week? I see "at most 24 hours", which means it could be even less than 24 hours, so there's no guarantee. Please see: https://www.backblaze.com/b2/docs/b2_authorize_account.html https://www.backblaze.com/b2/docs/b2_authorize_account.html
- loxias 10y ago
  "-if an API call failed, I have to check for an additional error: a invalid token" In general it's considered good practice to always check return values and error codes. Not for all code, but just for the code you would like to work.
- truetraveller 10y ago
  @loxias. I do not understand your response. Of course one should check error codes. My point is: now there's one more thing that can go wrong and needs to be checked.
- FireBeyond 10y ago
  > -I have to do date arithmetic, what if my server clock is incorrect, How is your clock inaccuracy in any way the responsibility of a service provider (Backblaze or other)? From certificate expiry to inaccurate logging, and so on, complaining about "what if my clock is wrong, I have to date math in my app!" is precisely "solving the wrong problem".
- truetraveller 10y ago
  @FireBeyond Did you even read my reasoning? All I'm saying is that there is ADDITIONAL complexity know in relation to the other, simpler static key approach. Not shifting blame on Backblaze for my server clock being potentially inaccurate.

by d4l3k 10y ago

If you look at their API you'll see that the token can be cached for up to a week. I doubt that having a check if the token is up to date will add much complexity.

truetraveller 10y ago

It really does add complexity: -I have to store the cached token somewhere: -I have to do date arithmetic, what if my server clock is incorrect, -if an API call failed, I have to check for an additional error: a invalid token I don't mind complexity when it is needed, but I do not prefer complexity for no good reason. That being said, can it really be cached up to a week? I see "at most 24 hours", which means it could be even less than 24 hours, so there's no guarantee. Please see: https://www.backblaze.com/b2/docs/b2_authorize_account.html https://www.backblaze.com/b2/docs/b2_authorize_account.html

loxias 10y ago
"-if an API call failed, I have to check for an additional error: a invalid token" In general it's considered good practice to always check return values and error codes. Not for all code, but just for the code you would like to work.
truetraveller 10y ago
@loxias. I do not understand your response. Of course one should check error codes. My point is: now there's one more thing that can go wrong and needs to be checked.
FireBeyond 10y ago
> -I have to do date arithmetic, what if my server clock is incorrect, How is your clock inaccuracy in any way the responsibility of a service provider (Backblaze or other)? From certificate expiry to inaccurate logging, and so on, complaining about "what if my clock is wrong, I have to date math in my app!" is precisely "solving the wrong problem".
truetraveller 10y ago
@FireBeyond Did you even read my reasoning? All I'm saying is that there is ADDITIONAL complexity know in relation to the other, simpler static key approach. Not shifting blame on Backblaze for my server clock being potentially inaccurate.