Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Aximag
|
Posted - 2009.09.19 17:40:00 -
[1]
CCP, please know that some of us enjoy the API almost as much as the game. Please think about API uptime more...
|
Celebrain
1st Steps Academy Tread Alliance
|
Posted - 2009.09.19 19:10:00 -
[2]
I'm sure most API app writer agrees with you, in the sense that most have probably spent more time working with the API than playing the game during their development cycle.
However, when it's a choice between the api being shut off for hours or the whole game being shut off for hours... well, you know... it really really sux tho doesn't it.
On a related note, I'd like to make an appeal to API app writers: PLEASE PLEASE PLEASE ALWAYS ALWAYS ALWAYS design your app so that the whole thing doesn't blow up entirely when the API is down!!!! Yank that network cable out of the back of your computer and test it please... change the hosts file and test it there, and on and on.... What sux even more than the API being down is when thousands of killboards, forums, and many other useful tools we all depend on are all down at the same time. Even EVEmon won't show me the list of skills I've trained in the main view, uh, hello, it hasn't changed from an hour ago! so why don't you show me a cached version with that warning at the top alerting me it could be out of date? Everyone always please cache things and use last known good values when the API is down... and if you need it to accomplish some task, accept and queue things up until the API is back up, be tolerant of down times please as much as is possible in your app!!!
|
Aximag
|
Posted - 2009.09.19 23:16:00 -
[3]
In summary, test those corner cases!
|
Squizz Caphinator
First Flying Wing Inc Primary.
|
Posted - 2009.09.21 18:20:00 -
[4]
Originally by: Celebrain IOn a related note, I'd like to make an appeal to API app writers: PLEASE PLEASE PLEASE ALWAYS ALWAYS ALWAYS design your app so that the whole thing doesn't blow up entirely when the API is down!!!! Yank that network cable out of the back of your computer and test it please... change the hosts file and test it there, and on and on.... What sux even more than the API being down is when thousands of killboards, forums, and many other useful tools we all depend on are all down at the same time. Even EVEmon won't show me the list of skills I've trained in the main view, uh, hello, it hasn't changed from an hour ago! so why don't you show me a cached version with that warning at the top alerting me it could be out of date? Everyone always please cache things and use last known good values when the API is down... and if you need it to accomplish some task, accept and queue things up until the API is back up, be tolerant of down times please as much as is possible in your app!!!
Feel free to contribute, we could always use more people testing our apps.
|
Ninja Troll
|
Posted - 2009.09.21 21:38:00 -
[5]
Originally by: Aximag CCP, please know that some of us enjoy the API almost as much as the game. Please think about API uptime more...
So do you think the game is like a set of API calls, or the other way around?
I for one would love to see a cap fleet battle derived from API calls =]
|
Dragonaire
Caldari Corax. New Eden Retail Federation
|
Posted - 2009.09.22 04:15:00 -
[6]
In a way it really is CCP just has a shorter cache time but not always from some of the battle I've seen -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
SentryRaven
KIA Corp KIA Alliance
|
Posted - 2009.09.22 13:11:00 -
[7]
Anyone seen a post telling it will not come up with TQ today after extended DT? --------
|
Thuffyr Ewwith
CHON THE R0NIN
|
Posted - 2009.09.22 14:17:00 -
[8]
hum yes, a small com from ccp would be nice to explain where is again the bug with api. thx. T.
|
Salmack
Dynaverse Corporation Vertigo Coalition
|
Posted - 2009.09.22 15:21:00 -
[9]
Yes some use the API for every day things like Teamspeak, Forums and IM registrations as well as POS, Membership tracking and managment.
Please keep this inmind everytime you take this services down during Tranq uptime.
|
Barrington Farquharsen
The Arrow Project Morsus Mihi
|
Posted - 2009.09.22 16:07:00 -
[10]
Its good practice for us API programmers, no?
Lets you straighten out the kinks in your code to handle the API being down
Quote: Yes some use the API for every day things like Teamspeak, Forums and IM registrations as well as POS, Membership tracking and managment.
However, it does suck when it comes to things like the above. POS tracking though, cache cache cache?!
|
|
Sai'tu
Caldari
|
Posted - 2009.09.22 18:29:00 -
[11]
API news stuff http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1183210&page=1
- - - - - - - - - - -
- - - - - - - - - - - |
SentryRaven
KIA Corp KIA Alliance
|
Posted - 2009.09.23 07:06:00 -
[12]
Originally by: Barrington Farquharsen Its good practice for us API programmers, no?
Lets you straighten out the kinks in your code to handle the API being down
Hehe.... I have recently rewritten my vbulletin board to handle usergroup assignment via EVE API, including a cronjob that would remove people if they left the corp or their API turned invalid.
Mistake 1: The API Server being physically down is not equivalent to "API key invalid". 280 users removed.
Mistake 2: The EVE API Backend being disabled (error code 902) is not equivalent to "API Key invalid". 276 users removed.
Mistake 3: Yes, CCP can turn off the API while my script is already running. 232 users removed.
I think I have cornered all possible scenarios of the API being not available for some reason, so far my script has not kicked people it shouldn't have :)
The downside of the API being down atm is of course that new members cannot authenticate and receive access to alliance internal stuff.
I am also coding on a way to integrate TeamSpeak into my forums and said API authentication, which will mean people will not be able to register accounts with TS while API is down.
I am waiting for them to turn it back on for today, even if only for a few hours... --------
|
Celebrain
1st Steps Academy Tread Alliance
|
Posted - 2009.09.23 12:44:00 -
[13]
how about "server appears 'physically' up but still actively refuses to accept the tcp/ip connection"? or "DNS servers don't resolve the domain"? Really your code should only check for "known" errors of api key mismatch, or no longer in corp so access no longer applies, etc... and treat every other "unknown" error as the api being temporarily down... There are many ways of being down, more than we've thought of.
When the api is down it should simply still use the last values it had the last time it successfully connected. So it simply wouldn't kick anyone off while the api is down (last it knew they were all ok) but would "catch up" and boot everyone it should as soon as it came back up. Or it may not approve new registrations for new people while the api is down (last it knew unknown people weren't ok) but existing previously-known-good people could still login during api down time, and new registrations would work again when it came back up.
And in fact you probably don't want to remove people's registrations entirely when they lose access (or don't have it yet to begin with), just set the access level down to guest access and don't let them see anything sensitive anymore (or to begin with). This way they can fix their api key or rejoin the corp without having to re-register constantly. And it gives an appropriate temporary limbo state for when registering while the api is down too, instead of making them retry many times.
|
SentryRaven
KIA Corp KIA Alliance
|
Posted - 2009.09.23 15:53:00 -
[14]
Originally by: Celebrain *stuff*
Yeah, I pretty much addressed all of your stuff after the first "incident" with the API Server being down.
And I never delete users, just demote them to registered. --------
|
Celebrain
1st Steps Academy Tread Alliance
|
Posted - 2009.09.24 01:00:00 -
[15]
excellent! sounds like someone's doing it right then! kudos!
one good thing that perhaps may come of so much api down time is that it raises awareness of this kind of defensive error tolerant coding among more people.... yay ;)
|
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |