Pages: 1 2 3 4 :: [one page] |
|
Author |
Thread Statistics | Show CCP posts - 8 post(s) |
|
CCP Zymurgist
Gallente C C P
|
Posted - 2011.06.17 15:54:00 -
[1]
CCP Elerhino is here to tell us about the upcoming changes to the API for Incarna. You can read about the changes and how to test them in this dev blog.
Zymurgist Community Representative CCP NA, EVE Online Contact Us |
|
SXYGeeK
Gallente do you -Mostly Harmless-
|
Posted - 2011.06.17 16:00:00 -
[2]
IBC.
Looks good, through I'm worried my EVE HQ is going to be dead right away from permission errors.
are all errors included in this throttle? -We So SeXy |
Georgiy Giggle
The Sith Syndicate
|
Posted - 2011.06.17 16:07:00 -
[3]
Anyway, EVE MON works fine.
|
Abdiel Kavash
Caldari Paladin Order Fidelas Constans
|
Posted - 2011.06.17 16:09:00 -
[4]
Quote: So we're going to start with: if your IP passes 3 errors a minute your IP gets blocked for 3 minutes.
Now hold on for a second. I go to my enemy alliance's web site, try to register there thrice with gibberish for API, and deny them all access for 3 minutes? Possibly longer for repeated "offenses"?
Or do errors only mean malformed requests? ---
Originally by: Sporked EVE IS DYING RUN TO THE HILLS! WE MIGHT HAVE TO ENGAGE WITH OTHER PEOPLE IN THIS MMO! THEY MIGHT SHOOT AT US WHILE WE ARE BUSY HOLDING HANDS AND FROLICKING! AAAAAAAAAAAAAAA
|
Black Madness
|
Posted - 2011.06.17 16:12:00 -
[5]
Edited by: Black Madness on 17/06/2011 16:11:56 Not bad, but i personally don't like permanent IP banning.
|
Serpents smile
|
Posted - 2011.06.17 16:12:00 -
[6]
Quote: We're also quite sure that you'll let us know if we're wrong, as you always so diligently do.
What, who, us?
|
|
Chribba
Otherworld Enterprises Otherworld Empire
|
Posted - 2011.06.17 16:16:00 -
[7]
more stuff
Secure 3rd party service | in-game 'Holy Veldspar' Now /w voice |
|
MailDeadDrop
Rage and Terror
|
Posted - 2011.06.17 16:19:00 -
[8]
Originally by: CCP Elerhino MarketOrders will now only return a list of active and non-expired orders. This call was fetching way too much information from the datastore and we decided to alter the query in a simple way, filtering out all expired and processed orders.
A character can only have about 60 orders, correct? At any one time I'd guess an active trader could have that many expired/processed orders, too. I fail to see how that (120 orders) constitutes "fetching way too much" information. Could you elaborate on this a bit more, as I suspect that *recently* expired and processed orders have some value in the API. The tough part may be figuring out what constitutes "recently".
MDD
|
Squizz Caphinator
Woopatang
|
Posted - 2011.06.17 16:19:00 -
[9]
Some clarification please.
What is the definition of an API Error?
If I'm pulling requests that are obviously malformed?
= or =
If I'm processing 1k Character APIs and 3 of them fail with a 2xx Authentication Error Code (for the first time), then I am blocked for 3 minutes? -- EveChatter |
da go
|
Posted - 2011.06.17 16:22:00 -
[10]
Edited by: da go on 17/06/2011 16:22:23 TrollMode ON
Originally by: CCP Elerhino we have been extremely busy little bees
In the old days devs were brosefs.
TrollMode OFF --- I don't know! I don't know why I did it, I don't know why I enjoyed it, and I don't know why I'll do it again! Bart Simpson. |
|
Vessper
Indicium Technologies Hephaestus Forge Alliance
|
Posted - 2011.06.17 16:23:00 -
[11]
You really need to define EXACTLY what constitutes an error here. A lot of users will enter full API keys to obtain information on their characters but may not have roles in a corporation to successfully obtain corporate API data. In which case, the API returns an error code.
EveHQ Character App |
Shepard Book
|
Posted - 2011.06.17 16:23:00 -
[12]
I like the proactive approach on this. Good job.
|
Entity
X-Factor Industries Synthetic Existence
|
Posted - 2011.06.17 16:27:00 -
[13]
I can just see services being griefed using that error throttle now by people providing incorrect data on purpose.
There is NO way to know in advance if certain calls will produce an error or not! Also, high profile services with a lot of users will cause a lot more errors, even though it's probably only like 0.01% of the total requests.
I'd say, just change your API to better deal with errors instead of dumping the responsibility of never failing a request on the 3rd party developers. _
Got Item? | EVE API? | Cache? |
Arkady Sadik
Minmatar Electus Matari
|
Posted - 2011.06.17 16:31:00 -
[14]
Thanks for the update.
About the error throttling: There is currently no error-free way to find out for a contact entry in the contacts list if it's a character, corporation or alliance. The only way to find out is "trial and error":
- If the ID is in the alliance list, it's an alliance (doh) - If you get a valid CorporationSheet, it's a corp (if not: error) - If you get a valid CharacterInfo, it's a character (if not: error) - Else it's a disbanded alliance
Would it be possible to get a API call to identify those IDs, or include a typeID in the contacts API?
|
MailDeadDrop
Rage and Terror
|
Posted - 2011.06.17 16:33:00 -
[15]
Originally by: Entity high profile services with a lot of users will cause a lot more errors, even though it's probably only like 0.01% of [ their ] total requests.
Actually, I think that points to an improvement to the error throttling..
Setting aside for the moment what constitutes an error, it is obvious that CCP will be tracking requestor IP addresses along with an error count. Instead, can CCP track the address and error *rate*? So that if the error rate exceeds the allowed maximum, then the lockouts begin?
MDD
|
da go
|
Posted - 2011.06.17 16:36:00 -
[16]
Quote: The basic theory we used here is that if nobody is complaining then we're not strict enough
Translation:
Winers drive our development. --- I don't know! I don't know why I did it, I don't know why I enjoyed it, and I don't know why I'll do it again! Bart Simpson. |
Abdiel Kavash
Caldari Paladin Order Fidelas Constans
|
Posted - 2011.06.17 16:44:00 -
[17]
Edited by: Abdiel Kavash on 17/06/2011 16:46:21
Originally by: MailDeadDrop
Originally by: CCP Elerhino MarketOrders will now only return a list of active and non-expired orders. This call was fetching way too much information from the datastore and we decided to alter the query in a simple way, filtering out all expired and processed orders.
A character can only have about 60 orders, correct? At any one time I'd guess an active trader could have that many expired/processed orders, too. I fail to see how that (120 orders) constitutes "fetching way too much" information. Could you elaborate on this a bit more, as I suspect that *recently* expired and processed orders have some value in the API. The tough part may be figuring out what constitutes "recently".
MDD
My skills currently allow about 130 outstanding orders on one character, and I am nowhere near maxed. Barely decent I'd say.
I'll just say that this will be a (minor) pain in the ass - seeing completed orders lets me know what goods I need to restock. Obviously I don't remember or keep track of 60-70 items I'm selling to see which one sold out. Now the only way to find out is continuously pulling the API and looking for disappearing orders. ---
|
Matalino
|
Posted - 2011.06.17 16:48:00 -
[18]
Edited by: Matalino on 17/06/2011 16:55:53
Originally by: Vessper You really need to define EXACTLY what constitutes an error here.
This definately needs clarification. The point that I am most concerned about is that error responses are currently the only way to detect if an account is active when using the limited API key. In order to minimize the impact on applications that use a large number of keys, we need to have a means of checking if a key is active without triggering the error counter.
Even an application that uses a small number of keys will probably be impacted by the timers if more than two keys are for inactive accounts. Everytime an application encounters two inactive accounts it must avoid querying any potentially inactive accounts for one minute in order to avoid the three minute lock out. This significantly increases the complexity of all but the most basic applications. If more than one application is running it would be completely impractical to avoid being locked out because of queries using inactive keys.
Originally by: Vessper A lot of users will enter full API keys to obtain information on their characters but may not have roles in a corporation to successfully obtain corporate API data. In which case, the API returns an error code.
Corp roles can be detected by first querying the character sheet. The character sheet will indicate if the character has the roles required to access the corp API. There is no need for an application to rely on error responses to detect corp roles.
|
Entity
X-Factor Industries Synthetic Existence
|
Posted - 2011.06.17 16:48:00 -
[19]
Oh and let's not forget the fact CCP wants to us to cough up $99 for a commercial license, yet we'd still run the risk of being locked out of one of the most essential features?
Because we sent a few bogus requests?
REALLY? _
Got Item? | EVE API? | Cache? |
Missy Sasha
|
Posted - 2011.06.17 16:53:00 -
[20]
Sounds like I'm going to get banned for using evemon. Bad form.
|
|
Abdiel Kavash
Caldari Paladin Order Fidelas Constans
|
Posted - 2011.06.17 16:58:00 -
[21]
Originally by: Matalino
Originally by: Vessper A lot of users will enter full API keys to obtain information on their characters but may not have roles in a corporation to successfully obtain corporate API data. In which case, the API returns an error code.
Corp roles can be detected by first querying the character sheet. The character sheet will indicate if the character has the roles required to access the corp API. There is no need for an application to rely on error responses to detect corp roles.
Even so, it's a question of which takes less resources, both on the server and client side: calling one API method which might in rare cases throw an error (most likely misuse or people dropping roles), or calling two methods every time?
Sometimes "sorry, no results" is just as good response as getting the results themselves. ---
|
Matalino
|
Posted - 2011.06.17 17:08:00 -
[22]
Edited by: Matalino on 17/06/2011 17:12:47
Originally by: Abdiel Kavash
Originally by: Matalino
Originally by: Vessper A lot of users will enter full API keys to obtain information on their characters but may not have roles in a corporation to successfully obtain corporate API data. In which case, the API returns an error code.
Corp roles can be detected by first querying the character sheet. The character sheet will indicate if the character has the roles required to access the corp API. There is no need for an application to rely on error responses to detect corp roles.
Even so, it's a question of which takes less resources, both on the server and client side: calling one API method which might in rare cases throw an error (most likely misuse or people dropping roles), or calling two methods every time?
Sometimes "sorry, no results" is just as good response as getting the results themselves.
If the error rate is low (less than three errors per minute) then there is no problem with the lockout trigger and the application can continue to use errors to detect corp roles.
If the application is going to be making enough queries to trigger the lockout, then it is probably better to query the character sheet first to verify permissions.
|
Andrea Griffin
|
Posted - 2011.06.17 17:11:00 -
[23]
Edited by: Andrea Griffin on 17/06/2011 17:12:59
Originally by: Black Madness Not bad, but i personally don't like permanent IP banning.
Same. For those of us whose IP address changes on a semi-regular basis, it would really suck to be assigned the address of some derp face who had earlier abused the API. Make it a few days or a week, but permanent doesn't sound all that great.
- "When I nerf something, it takes 2-3 months for your dreams to be crushed." - CCP Big Dumb Object |
Jason Edwards
Internet Tough Guy Spreadsheets Online
|
Posted - 2011.06.17 17:25:00 -
[24]
So developers while trying to code cant make mistakes else they get banned?
Richard Stallman wrote a program that divides by zero.
Richard Stallman can make infinite loops end. ------------------------ To make a megathron from scratch, you must first invent the eve universe.
|
Matalino
|
Posted - 2011.06.17 17:28:00 -
[25]
Edited by: Matalino on 17/06/2011 17:31:29
Originally by: Jason Edwards So developers while trying to code cant make mistakes else they get banned?
They can make mistakes. They are just limited to one or two mistakes per minute. If a program triggers the lockout, it is not unreasonable to spend 3 minutes finding and correcting the problem, at which point the lockout will have expired. Bans are for those who spend more time locked out than not. I expect that there should be no problem with getting locked out a few time a day while developing a program.
|
Matalino
|
Posted - 2011.06.17 17:41:00 -
[26]
Edited by: Matalino on 17/06/2011 17:44:26
Originally by: CCP Zymurgist CCP Elerhino is here to tell us about the upcoming changes to the API for Incarna.
Can we please get some clarification on when this change is going live? I hope this is not going into effect for June 21. A single weekend is certainly not enough time for developers to adapt to any change let alone one so drastic. If the change must go live on that date, at least dial down the restriction to allow for a higher initial error rate until developers have a chance to code responses to the change.
|
|
CCP Stillman
|
Posted - 2011.06.17 17:56:00 -
[27]
As the dev blog states, our intent is to keep a consistent level of service for the API.
It's not the intent to be cause legitimate applications grief at all. Quite the opposite, because we want to give legitimate users and applications the best possible experience, for which we need throttling to make sure that the API's performance doesn't significantly degrade in the event of unusual requests are made excessively by any one entity.
It is however a valid concern you all raise. And it's something we aim to not have become a problem through tweaking the settings so that legit users won't feel it. Based on this, we'll make sure that the initial threshold is high enough that legitimate developers don't get bit by this, as it's not the intent.
I might add that this is an extension to our already existing policy where we block IPs that cause excessive errors. Note that "permanent" bans are only given out in the most extreme cases. And if that occurs, you can file a petition and we will lift the ban on your IP if you promise to fix whatever caused excessive requests.
Again, the intent is not to cause anybody to be blocked. It's to ensure that applications do not negatively affect the API if they do not respect errors and the like. We will tweak the throttling to ensure that legitimate users aren't affected. I'll talk to Elerhino on Monday, and discuss about raising the throttling threshold, if you're concerned about it being too low. Because you shouldn't be.
|
|
Sino Sarn
Sick Tight BricK sQuAD.
|
Posted - 2011.06.17 18:07:00 -
[28]
Nerf supers, already.
|
Risingson
Mezzanine Inc
|
Posted - 2011.06.17 18:24:00 -
[29]
there would have to be a way to validate a users userid/apikey combo without causing an error counting towards that throttle.
// Eveeye.com :: IPS Solarsystem Intel & Info |
Assaj Ventress
|
Posted - 2011.06.17 18:31:00 -
[30]
CCP Stillman, while you are here, can you please clarify what exactly is considered en errouneous request? -----------------
|
|
El'Niaga
Minmatar Republic Military School
|
Posted - 2011.06.17 18:32:00 -
[31]
Originally by: CCP Stillman As the dev blog states, our intent is to keep a consistent level of service for the API.
It's not the intent to be cause legitimate applications grief at all. Quite the opposite, because we want to give legitimate users and applications the best possible experience, for which we need throttling to make sure that the API's performance doesn't significantly degrade in the event of unusual requests are made excessively by any one entity.
It is however a valid concern you all raise. And it's something we aim to not have become a problem through tweaking the settings so that legit users won't feel it. Based on this, we'll make sure that the initial threshold is high enough that legitimate developers don't get bit by this, as it's not the intent.
I might add that this is an extension to our already existing policy where we block IPs that cause excessive errors. Note that "permanent" bans are only given out in the most extreme cases. And if that occurs, you can file a petition and we will lift the ban on your IP if you promise to fix whatever caused excessive requests.
Again, the intent is not to cause anybody to be blocked. It's to ensure that applications do not negatively affect the API if they do not respect errors and the like. We will tweak the throttling to ensure that legitimate users aren't affected. I'll talk to Elerhino on Monday, and discuss about raising the throttling threshold, if you're concerned about it being too low. Because you shouldn't be.
Now don't take this the wrong way, but you know your corporation released a new forum without even the most basic security implemented (which they then had to take the forums down but once again have them in test.....waste of resources). So you have to realize most people are very skeptical of CCP these days.
Instead of Devs that love the game and want to put out new and exciting ships/mods etc as CCP was in the early days, we seem the last year or two to have bean counters in charge. Bean counters produce lackluster expansions because they are cheap. They slowly run games into a ground because they don't love a game they only see dollar signs. Take the bean counter syndrome to far and you face the 2005 collapse that SWG suffered with the NGE.
What you really need to do for the Winter expansion is at least 20 new ships of new roles (that's 5 per race...1 frig, 1 destroyer, 1 cruiser, 1 battlecruiser, 1 battleship, and 1 capital very doable), with mods etc to support them. This is a spaceship game, that hasn't had significant new ships in over 2 years. If you have any dwindling revenue streams etc, that is the source. You could use multiple entries from the various ship contests, just because the winner was guaranteed doesn't mean you can't use others to help cut down development time.
Bean counters are unimaginitive, and that's why they eventually run all games into the ground.
|
Vessper
Indicium Technologies Hephaestus Forge Alliance
|
Posted - 2011.06.17 18:32:00 -
[32]
Originally by: CCP Stillman As the dev blog states, our intent is to keep a consistent level of service for the API.
It's not the intent to be cause legitimate applications grief at all. Quite the opposite, because we want to give legitimate users and applications the best possible experience, for which we need throttling to make sure that the API's performance doesn't significantly degrade in the event of unusual requests are made excessively by any one entity.
It is however a valid concern you all raise. And it's something we aim to not have become a problem through tweaking the settings so that legit users won't feel it. Based on this, we'll make sure that the initial threshold is high enough that legitimate developers don't get bit by this, as it's not the intent.
I might add that this is an extension to our already existing policy where we block IPs that cause excessive errors. Note that "permanent" bans are only given out in the most extreme cases. And if that occurs, you can file a petition and we will lift the ban on your IP if you promise to fix whatever caused excessive requests.
Again, the intent is not to cause anybody to be blocked. It's to ensure that applications do not negatively affect the API if they do not respect errors and the like. We will tweak the throttling to ensure that legitimate users aren't affected. I'll talk to Elerhino on Monday, and discuss about raising the throttling threshold, if you're concerned about it being too low. Because you shouldn't be.
We still need clarification as to what constitutes an "unusual request" under these new rules. Is it certain error codes? All error codes? Malformed requests? Without this information, it's going to be hard to know what you guys are getting at and therefore how to make our apps more compliant.
Also, is this something that will be deployed next week?
EveHQ Character App |
Azazel Mordred
Minmatar Cloak of Shadows
|
Posted - 2011.06.17 18:46:00 -
[33]
Cool, I'm all for some attempts to improve the API's performance, and blocking repeated erroneous requests seems like a pretty reasonable idea.
I'll just echo the concerns already noted though, about what conditions exactly add to the counter which results in an IP block.
In addition to the obvious "griefing" opportunities presented by providing false API information to someone's service, I would imagine blocking due to requests to a data set before it's cache expiry would constitute a blockable offence. Unfortunately I feel this may also be abused, or even more likely, sites and services ending up inadvertently blocking themselves because a user is perhaps trying to use multiple services, or has signed up on one which is doing regular polling causing the rest to fail.
It's easy for such services to reject that user's API for a while *after* receiving errors, but you have to try it to know the result.
I think there are way too many API calls which you have no way of knowing will fail, until they have been called and returned an error - by which time you've got yourself blocked!
|
Lumy
Minmatar Sebiestor Tribe
|
Posted - 2011.06.17 19:23:00 -
[34]
LOL, CCP CMS fail. I believe you meant
<eveapi version="2"> <currentTime>2011-06-21 13:18:52</currentTime> <error code="904">Your IP address has been temporarily blocked because it is causing too many errors. See the cacheUntil timestamp for when it will be opened again. IPs that continually cause a lot of errors in the API will be permanently banned, please take measures to minimize problematic API calls from your application.</error> <cachedUntil>2071-06-21 13:21:50</cachedUntil> </eveapi>
instead of
2011-06-21 13:18:52 Your IP address has been temporarily blocked because it is causing too many errors. See the cacheUntil timestamp for when it will be opened again. IPs that continually cause a lot of errors in the API will be permanently banned, please take measures to minimize problematic API calls from your application. 2071-06-21 13:21:50
Joomla! in EVE - IGB compatible CMS. |
Veldar Reku
Minmatar Wu Xi Holdings
|
Posted - 2011.06.17 19:50:00 -
[35]
Originally by: Chribba
So with "Smaller Data", so we'd need to double-check our previous active orders if they are not listed in the api it has been filled? Am I reading this correctly? /c
Co-ordinate with wallet transactions to know for certain.
But generally yes, if the order is NOT expired and it is no longer active, then it must have been filled or canceled.
|
Lutz Major
|
Posted - 2011.06.17 20:00:00 -
[36]
Originally by: Matalino rants implying nobody can code
You do realise, that you can query several dozens of API calls in under a minute? I'm quering all available APIs of my six characters and three corporations in about 12 seconds. But I know, which roles every char has and know, when roles change.
With foreign chars, I can't know and would have to query for restricted/full API key (okay these won't change), query the corp, query different corp pages, ...
--------
The other thing about the only active MarketOrders. Wouldn't it be possible to have the inactive orders at least once in a call (or up to a week)? So we could determine, whether they were cancelled/fullfilled/expired? That might help for corporation orders, where everyone could cancel them.
|
Florestan Bronstein
draketrain Test Alliance Please Ignore
|
Posted - 2011.06.17 20:05:00 -
[37]
Originally by: MailDeadDrop A character can only have about 60 orders, correct?
more like 300
|
Lutz Major
|
Posted - 2011.06.17 20:12:00 -
[38]
Originally by: Veldar Reku Co-ordinate with wallet transactions to know for certain
I know, it's pretty far fetched, but:
Char A creates a corp sell order for ISK 8.20 Char A creates a corp sell order for ISK 8.50 ... Someone buys in bulk for ISK 8.9 ... Char B cancelles the second order for ISK 8.5 and creates a new order for ISK 9.0 ...
You can't determine which order was filled and which was cancelled :(
|
Wollari
Phoenix Industries Saints Amongst Sinners
|
Posted - 2011.06.17 20:50:00 -
[39]
You really should take care of the blocking thing. If somebody don't like DOTLAN for example, he would be funny enough wrong api keys in my registration panel and block my IP for X amount of time, blocking all DOTLAN map/sov/alliance requests just because someone is abusing my user api section.
The only change for me would be to actually use 2 different IPs. 1 for user bull**** and user generated api requests and one for the more important database and site updates. So site updates won't get blocked when someone is abusing my user section.
hmmmmm
|
Wollari
Phoenix Industries Saints Amongst Sinners
|
Posted - 2011.06.17 20:59:00 -
[40]
When Incarna evolves, I hope we get Incarna related APIs and IGB Browser headers aswell (like position in the station, section, etc)
|
|
Epitrope
The Citadel Manufacturing and Trade Corporation
|
Posted - 2011.06.17 21:22:00 -
[41]
Originally by: devblog Smaller Data
MarketOrders will now only return a list of active and non-expired orders. This call was fetching way too much information from the datastore and we decided to alter the query in a simple way, filtering out all expired and processed orders. This is potentially a big change but we figured most people are calling this to watch their active orders and for historic information they get their transactions. We're also quite sure that you'll let us know if we're wrong, as you always so diligently do.
Originally by: eve-dev wiki orderState byte Valid states: 0 = open/active, 1 = closed, 2 = expired (or fulfilled), 3 = canceled, 4 = pending, 5 = character deleted.
How do we find out about orders which are created and destroyed between API calls?
|
Matalino
|
Posted - 2011.06.17 21:42:00 -
[42]
Edited by: Matalino on 17/06/2011 21:45:48
Originally by: Lutz Major
Originally by: Matalino rants implying nobody can code
You do realise, that you can query several dozens of API calls in under a minute? I'm quering all available APIs of my six characters and three corporations in about 12 seconds. But I know, which roles every char has and know, when roles change.
I don't know where you get the impression that I was ranting or that I was implying that nobody can code.
Originally by: Lutz Major
Originally by: Veldar Reku Co-ordinate with wallet transactions to know for certain
I know, it's pretty far fetched, but:
Char A creates a corp sell order for ISK 8.20 Char A creates a corp sell order for ISK 8.50 ... Someone buys in bulk for ISK 8.9 ... Char B cancelles the second order for ISK 8.5 and creates a new order for ISK 9.0 ...
You can't determine which order was filled and which was cancelled :(
First, Char B cannot cancel an order created by Char A.
Second, you can determine which order was filled based on the fact that the lowest priced order must always be filled before the higher priced order. This rule will allow you to determine which order was cancelled in all but the most specialized situation.
Finally, does it really matter which of the two orders was cancelled, and which one was filled? Aside from idle curiosity, why would you want to have this information?
Originally by: Epitrope How do we find out about orders which are created and destroyed between API calls?
The wallet transaction log will record the purchase of any items, and the wallet journal will record broker fees. If the order was created and cancelled without being filled at all, you will have no record of what was ordered, but you will still have a record of the broker fees. In both cases, this may present a challenge for those who correlate Market Order creation times with Broker Fee timestamps to account for those broker fees. Keeping some history of completed market orders would allow for easy accounting of broker fees.
|
Risingson
Mezzanine Inc
|
Posted - 2011.06.17 22:45:00 -
[43]
Originally by: Wollari When Incarna evolves, I hope we get Incarna related APIs and IGB Browser headers aswell (like position in the station, section, etc)
current Incursions API first please :)
// Eveeye.com :: IPS Solarsystem Intel & Info |
Epitrope
The Citadel Manufacturing and Trade Corporation
|
Posted - 2011.06.17 23:20:00 -
[44]
Originally by: Matalino Finally, does it really matter which of the two orders was cancelled, and which one was filled? Aside from idle curiosity, why would you want to have this information?
...
If the order was created and cancelled without being filled at all, you will have no record of what was ordered, but you will still have a record of the broker fees.
We're giving examples of data that are being taken away by the change to the behavior of MarketOrders, in the hope that that change won't go through. You've given workarounds, and that's good, but workarounds shouldn't be necessary and don't address our concerns.
|
Doktor Csernus
|
Posted - 2011.06.17 23:41:00 -
[45]
The problem is the user input....
|
Matalino
|
Posted - 2011.06.18 00:52:00 -
[46]
Originally by: Epitrope We're giving examples of data that are being taken away by the change to the behavior of MarketOrders, in the hope that that change won't go through. You've given workarounds, and that's good, but workarounds shouldn't be necessary and don't address our concerns.
CCP Elerhino stated that they wish to remove this extra data from the Market Orders API in order to reduce load on the server. If we want them to keep it, then we will likely need a reason that has more substance than "idle curiosity" or for the convenience of a few programmers. Discussing the issue in this thread has revealed a specific reason to keep that data. Without this data, it is impractical to match broker fees to market orders that are created and filled/cancelled within the cache timer. For this reason, I agree that CCP should leave completed orders on the API for at least a few hours.
|
Ranka Mei
Caldari
|
Posted - 2011.06.18 01:06:00 -
[47]
This looks like another braindead idea on the part of CCP to me (like charging 3rd parties for use of the API: that was a real whopper).
Banning IP addresses of people using the API, however temporarily, is barking up the wrong tree, as no one using these 3rd party apps has any real influence over how the app itself handles API requests.
Again CCP appears to be targetting the wrong folks. It's almost like they're purposely sabotaging their own game. --
|
Aineko Macx
|
Posted - 2011.06.18 04:54:00 -
[48]
Originally by: CCP Stillman stuff
I am intrigued you wrote so much text yet didn't answer the most direct questions in the thread. ________________________ CCP: Where fixing bugs is a luxury, not an obligation. |
Viktor Del'Grande
|
Posted - 2011.06.18 05:55:00 -
[49]
Dont fool around, you have lost most of your reputation to me. You are preparing for "premium api services". *Damned 'BizDev' Team*
|
Lenner Shakiel
|
Posted - 2011.06.18 06:56:00 -
[50]
Can we see easier ways to access the API, maybe a email to option for applications that can extract from email or eve mail option for corporations requiring API for recruitment?
|
|
Consortium Agent
|
Posted - 2011.06.18 07:18:00 -
[51]
Edited by: Consortium Agent on 18/06/2011 07:25:26 O M F G...
Somebody pinch me... please? I must be dreaming. Did CCP not just slap their d*cks in the face of their most ardent supporters - the development community - with some bullsh*t commercial license money grabbing scheme a few days ago?
And now you rush out a devblog a mere handful of days before a new release because it 'fell through the cracks' that tells us 'we've changed some stuff and, oh yeah, if you cause a lot of errors accessing our sh*tty API... you'll be auto-banned'.
How many of us developers that you just d*ck slapped do you honestly think even have the desire to now go rush and fix our applications days before the release of a new API that will penalize us if we don't? This is *exactly* the kind of BS support we've always gotten from CCP with the API... and now you want to charge us what amounts to another year subscription just to access it.
Edit: Oh yeah - almost forgot. Many have asked for clarification. As usual. We have to ask for clarification in the first place. But in either case - you never answer the questions. What *should* we consider an error, exactly? I'm sure you'll tell us one day... oh wait, nvm... right - we've always figured it out *by ourselves* before.
I have only two words left for you CCP... there's only two words that could possibly express how I feel about you, your game and all your stupid BS...
F*CK YOU!
|
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.06.18 08:48:00 -
[52]
I don't like the change to the Market Orders API.
What about the following? You have this nifty little oderState flag in your database/API already. How about adding this as a paramater to the Market Order API query?
This way the dev has control over what data he receives. Those that only need the active orders could just add that parameter to their query. You even so far and go with orderState=0 (Active) as the default setting if the orderState parameter isn't passed along in the query. That way you would benefit from reduced traffic from those apps that are "too lazy" to implement the change.
Parsing through three different APIs (Market Order, Wallet Journal, Wallet Transaction) to find out which sounds like a weird thing to do in order to find out which order expired.
Bonus points for adding a parameter for issueDate (return orders issued on issueDate and later)
Re: Blocking IPs. We really, really need a dedicated API that lets us verify the provided API key vs. desired API. -- EVEWalletAware - an offline wallet manager |
Josef Huffenpuff
Caldari
|
Posted - 2011.06.18 11:06:00 -
[53]
I just want to re-iterate what everybody else is asking here and we do not have a proper answer for ....
3 Errors a minute on average over a day, all day, every day is probably too much and sounds like a feasable way to cut down on excessive erronous API calls.
But...
Its really easy to generate three API errors in as many seconds when validating API keys on an SMF forum for example. However, we wont normally try again for at least an hour. We don't want to be banned for that even for 3 minutes because that's a major PITA and most software will keep hammering the server anyway until it gets a good answer.
|
clixor
Celluloid Gurus
|
Posted - 2011.06.18 11:11:00 -
[54]
Originally by: Viktor Del'Grande Dont fool around, you have lost most of your reputation to me. You are preparing for "premium api services". *Damned 'BizDev' Team*
This, it's not uncommon to use full API for a variety of applications. What's next, data limit per account? extra fees for handling data?
As we're talking about small amount of data per user, i can't escape the feeling the motivation for the change is somewhat completely different.
|
Vaerah Vahrokha
Minmatar Vahrokh Consulting
|
Posted - 2011.06.18 11:42:00 -
[55]
Originally by: "CCP Elerhino"
Smaller Data MarketOrders will now only return a list of active and non-expired orders. This call was fetching way too much information from the datastore and we decided to alter the query in a simple way, filtering out all expired and processed orders. This is potentially a big change but we figured most people are calling this to watch their active orders and for historic information they get their transactions. We're also quite sure that you'll let us know if we're wrong, as you always so diligently do.
I don't know why I even bother providing feedback with the kick in the balls you just gave us with the new CCP "lollicense".
Anyway since I am an idiot, I am still going to provide an useful feedback: you are gooing to kill 70% of the applications using the market API.
Most people don't (just) want to know if their orders are active but want to gather statistics about their recent past performance over time.
If you remove the expired orders (and no option to fetch them in any way) then you will achieve the opposite of what you worked for: with no past history, the apps will need to be run continuously, overloading your API service. With the history, they need to be run about once per month instead.
What do you prefer? Every day to fetch 160 orders or once a month to fetch 1000?
Auditing | Research | 3rd Party | Collateral Holding | EvE RL Charity |
Daedalus II
Helios Research
|
Posted - 2011.06.18 12:49:00 -
[56]
If this new developer license deal is being implemented, why not require the license key to be trasmitted in each api request? That way you will know exactly which program sends erroreneous requests or too many requests. You can then contact the deveolper of the program and tell them to fix it. If it isn't fixed within x amount of time you block all requests (from anyone) with that license key.
___________ Interested in incursions? Join Helios Research! |
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.06.18 13:23:00 -
[57]
Originally by: Daedalus II If this new developer license deal is being implemented, why not require the license key to be trasmitted in each api request? That way you will know exactly which program sends erroreneous requests or too many requests. You can then contact the deveolper of the program and tell them to fix it.
No need for a developer key to do that.
Other and I already send HTTP headers ("X-Developer-Contact" <email address> and "X-Application-Info" <app name>, in my case) with each API request. -- EVEWalletAware - an offline wallet manager |
Doktor Csernus
|
Posted - 2011.06.18 15:29:00 -
[58]
Edited by: Doktor Csernus on 18/06/2011 15:33:28
Originally by: Josef Huffenpuff I just want to re-iterate what everybody else is asking here and we do not have a proper answer for ....
3 Errors a minute on average over a day, all day, every day is probably too much and sounds like a feasable way to cut down on excessive erronous API calls.
But...
Its really easy to generate three API errors in as many seconds when validating API keys on an SMF forum for example. However, we wont normally try again for at least an hour. We don't want to be banned for that even for 3 minutes because that's a major PITA and most software will keep hammering the server anyway until it gets a good answer.
Yea, I could use an answer for this question too.
As I've said earlier, its pretty easy to get banned via the API verify process if the user inpunts are incorrect. I can check if the User ID isnt NaN and if the API key is exactly 64 char long, but even if I do it... any false data with "132456" user id and 64 of 'A' letter would go thru a JS verifiy and come back from EVE API with auth error.
CCP, please clarify the "error" calls. All of them? Are you killing the private/corporation/alliance sites with third party api tools for not having license?
|
Xenofarion
Gallente Swords Horses and Heavy Metal
|
Posted - 2011.06.18 16:20:00 -
[59]
Edited by: Xenofarion on 18/06/2011 16:22:14
Originally by: CCP Stillman Note that "permanent" bans are only given out in the most extreme cases.
But you do know that most ISPs use dynamic IPv4?
This means when someone is screwing up and gets a permanent ban, but I happen to get that IP in the future, my EVEmon won't work for a day and miraculously work again the next day when I have a new IP again?
And if someone was a terrible troll (what totally couldn't happen on the internet), he could get his IP banned by flooding the API deliberately with wrong calls, then fetching a new IP, get it banned, rinse repeat? (bots *cough*)
This would result in some nice "Wtf why isn't my [application XYZ] working any more?" posts.
It's not like you haven't been in the crosshair of a malicious group that has access to a relatively big Bot-net recently.. -- those who can, do those who can't, complain
|
Marcel Devereux
Aideron Robotics
|
Posted - 2011.06.18 17:39:00 -
[60]
Please be very clear on what errors will cause a temporary or permanent ban. If outdated keys will cause any kind of ban you will need to provide a way for sites to check to see if a set of keys are still valid. This API call would also not result in any kind of ban unless the request was malformed.
|
|
Sherksilver
|
Posted - 2011.06.18 22:45:00 -
[61]
Please, Please, Please GIVE US DETAILS ON WHAT AN ERROR REALLY IS! - I dunno about the rest of you - but I find it extremely difficult to protect against something - when I do not know what I need to protect against....
Helps us devs out here CCP.
|
|
CCP Stillman
|
Posted - 2011.06.18 23:20:00 -
[62]
Originally by: Marcel Devereux Please be very clear on what errors will cause a temporary or permanent ban. If outdated keys will cause any kind of ban you will need to provide a way for sites to check to see if a set of keys are still valid. This API call would also not result in any kind of ban unless the request was malformed.
Right now any error will count towards a temporary throttle.
And just to be clear, you have to be very persistent to get your IP blocked from the API. And should that occur, you just need to file a petition to get unblocked.
And you're completely right about the fact that if you want to validate a lot of keys at once, then this would be bad for you. Right now, we'll have to mitigate that by allow you to do more errors per minute. With the customizable API keys, we can make sure that the APIKeyInfo call, which gives you information about the key, doesn't actually throttle you.
It's weekend right now. Come Monday, I'll talk to him about raising the initial errors/minute threshold to something more sane, as I agree that initially 3 errors/minute is gonna cause a lot of trouble. We'll look into raising this considerably. Once I know something, I'll let you all know.
|
|
|
CCP Stillman
|
Posted - 2011.06.18 23:26:00 -
[63]
Originally by: Xenofarion Edited by: Xenofarion on 18/06/2011 16:22:14
Originally by: CCP Stillman Note that "permanent" bans are only given out in the most extreme cases.
But you do know that most ISPs use dynamic IPv4?
This means when someone is screwing up and gets a permanent ban, but I happen to get that IP in the future, my EVEmon won't work for a day and miraculously work again the next day when I have a new IP again?
And if someone was a terrible troll (what totally couldn't happen on the internet), he could get his IP banned by flooding the API deliberately with wrong calls, then fetching a new IP, get it banned, rinse repeat? (bots *cough*)
This would result in some nice "Wtf why isn't my [application XYZ] working any more?" posts.
It's not like you haven't been in the crosshair of a malicious group that has access to a relatively big Bot-net recently..
Again, if your IP is blocked, all you have to do is just file a petition and we'll unblock your IP. But I hope you realize that at the end of the day, we have to make sure that we can provide a consistent quality of service. We have no way of identifying the user of a particular IP. As such, all we can do is block an IP which is causing a higher load on the API than we accept and if they're legitimate users, we just unblock them when they contact us.
|
|
|
CCP Stillman
|
Posted - 2011.06.18 23:31:00 -
[64]
Originally by: Ranka Mei
Banning IP addresses of people using the API, however temporarily, is barking up the wrong tree, as no one using these 3rd party apps has any real influence over how the app itself handles API requests.
We've been employing a policy of blocking IPs that cause excessive errors already. And so far, of the handful of times we've had to block anybody, it has yet to be an actual end-user we've had to block. But rather, developers who didn't respect errors and did large amounts of errors.
|
|
Marcel Devereux
Aideron Robotics
|
Posted - 2011.06.19 03:29:00 -
[65]
Originally by: CCP Stillman
Originally by: Marcel Devereux Please be very clear on what errors will cause a temporary or permanent ban. If outdated keys will cause any kind of ban you will need to provide a way for sites to check to see if a set of keys are still valid. This API call would also not result in any kind of ban unless the request was malformed.
Right now any error will count towards a temporary throttle.
And just to be clear, you have to be very persistent to get your IP blocked from the API. And should that occur, you just need to file a petition to get unblocked.
And you're completely right about the fact that if you want to validate a lot of keys at once, then this would be bad for you. Right now, we'll have to mitigate that by allow you to do more errors per minute. With the customizable API keys, we can make sure that the APIKeyInfo call, which gives you information about the key, doesn't actually throttle you.
It's weekend right now. Come Monday, I'll talk to him about raising the initial errors/minute threshold to something more sane, as I agree that initially 3 errors/minute is gonna cause a lot of trouble. We'll look into raising this considerably. Once I know something, I'll let you all know.
Thanks for the clarification! The APIKeyInfo API will probably solve 99% of the concern in this thread. Would it be possible to hold off on this throttling until we have that?
|
Epitrope
The Citadel Manufacturing and Trade Corporation
|
Posted - 2011.06.19 08:37:00 -
[66]
Originally by: CCP Stillman Right now any error will count towards a temporary throttle.
Does this include error 520 "Unexpected failure accessing database" and other server-side errors? When there's a response delay and several calls all return an error at once, getting banned (especially from other, working API calls) is undesirable.
|
Vessper
Indicium Technologies Hephaestus Forge Alliance
|
Posted - 2011.06.19 22:13:00 -
[67]
We should have a way of verifying the userID, APIKey and the key type without it contributing towards our ban. At present, we have to rely on checking a particular API and look at the error response (if any) to decide the key type for use later on. This is far from ideal so if you're making the error throttling a priority, you should also be giving us a way to avoid making forced errors in our applications.
EveHQ Character App |
Sherksilver
|
Posted - 2011.06.20 00:21:00 -
[68]
Would also be nice to have the Character API update quickly when character roles change. For some API queries that require specific roles, if those change (yet character API does not update quickly) an app that is trying to access say - POS information can quickly run into issues (as that currently is the only way I know of to determine access allowed without generating an error off the bat).
|
Azazel Mordred
Minmatar Cloak of Shadows
|
Posted - 2011.06.20 05:12:00 -
[69]
I could be wrong, but I believe the Factional Warfare stats calls are also something you HAVE to generate an error on before you know if the character is enlisted or not.
|
|
CCP Stillman
|
Posted - 2011.06.20 13:43:00 -
[70]
For tomorrow's deployment we've upped number to 150 errors/minute before you get temporarily block for 3 minutes. I hope this helps. If not, we'll investigate other options for what we can do to mitigate the impact of throttling being in place.
|
|
|
Vandrion
Gallente The Collective B O R G
|
Posted - 2011.06.20 22:04:00 -
[71]
Originally by: CCP Stillman
Originally by: Xenofarion Edited by: Xenofarion on 18/06/2011 16:22:14
Originally by: CCP Stillman Note that "permanent" bans are only given out in the most extreme cases.
But you do know that most ISPs use dynamic IPv4?
This means when someone is screwing up and gets a permanent ban, but I happen to get that IP in the future, my EVEmon won't work for a day and miraculously work again the next day when I have a new IP again?
And if someone was a terrible troll (what totally couldn't happen on the internet), he could get his IP banned by flooding the API deliberately with wrong calls, then fetching a new IP, get it banned, rinse repeat? (bots *cough*)
This would result in some nice "Wtf why isn't my [application XYZ] working any more?" posts.
It's not like you haven't been in the crosshair of a malicious group that has access to a relatively big Bot-net recently..
Again, if your IP is blocked, all you have to do is just file a petition and we'll unblock your IP. But I hope you realize that at the end of the day, we have to make sure that we can provide a consistent quality of service. We have no way of identifying the user of a particular IP. As such, all we can do is block an IP which is causing a higher load on the API than we accept and if they're legitimate users, we just unblock them when they contact us.
Clarification on these please:
What category should the petition be filed under?
Will the petition be answered in a timely manner? For clarification my definition of a timely manner for this would be 24 hours or less.
|
Qoi
Exert Force
|
Posted - 2011.06.21 11:48:00 -
[72]
Edited by: Qoi on 21/06/2011 11:48:08 the error limit is now working at 150/minute instead of the original 3/minute, however the ban duration is not 3 minutes, but 150 minutes.
|
|
CCP Stillman
|
Posted - 2011.06.21 12:07:00 -
[73]
Originally by: Qoi Edited by: Qoi on 21/06/2011 11:48:08 the error limit is now working at 150/minute instead of the original 3/minute, however the ban duration is not 3 minutes, but 150 minutes.
The API wasn't supposed to be open yet. This will be fixed by the time it opens up
|
|
LifeHatesMe
|
Posted - 2011.06.21 13:35:00 -
[74]
Why not use a system similar to SPAMHAUS (email spam), block by ip temporarily. Block by subnet if it gets really excessive. Manual unblock requests get you unblocked. Even that is better than the current system which processes all errors. ______________________________ War... War never ends. |
Ikaef Giasep
|
Posted - 2011.06.21 19:36:00 -
[75]
Originally by: CCP Stillman
Originally by: Qoi Edited by: Qoi on 21/06/2011 11:48:08 the error limit is now working at 150/minute instead of the original 3/minute, however the ban duration is not 3 minutes, but 150 minutes.
The API wasn't supposed to be open yet. This will be fixed by the time it opens up
While the Server was down today, our corp killboard was querying the API once per hour. The IP of the Server got blocked by you guys. It has been unblocked meanwhile. Nonetheless it is Important that you fix the counting mechanism in such a way that a Service outage caused by CCP does not count towards the blocking count.
|
Ikaef Giasep
|
Posted - 2011.06.21 22:32:00 -
[76]
I sincerly request you to revert the MarketOrder API change immediately. By not providing expired orders anymore, market orders that were created and fulfilled between two API calls will go unnoticed.
The result would be that the MarketTransactions API call would return entries that cannot be related to any market order. Are we supposed to create our own arbitrary orderIDs for them to ensure referential data integrity? How do we know how many orders were created/fulfilled between two API calls if we had two unrelated market transactions? Are these two orders or a single order?
You guys screwed up by not following design principles like the "single responsibility principle" and "separation of concerns". The MarketOrder API call should be self-contained. It should not be required to use other API calls to understand it.
Again, please revert this change asap or provide a solution. Thank you.
|
Agnitio Reperio Augustus
Gallente The Scope
|
Posted - 2011.06.22 13:13:00 -
[77]
I have a few problems with Incarna. I try to download it, and it says there's a corrupt file or something. And THE WINDOW WON'T CLOSE! This happening to anyone else? |
Judy BigShot
Big Shot - For the Bounty Hunters
|
Posted - 2011.06.23 11:50:00 -
[78]
Originally by: Ikaef Giasep I sincerly request you to revert the MarketOrder API change immediately. By not providing expired orders anymore, market orders that were created and fulfilled between two API calls will go unnoticed.
The result would be that the MarketTransactions API call would return entries that cannot be related to any market order. Are we supposed to create our own arbitrary orderIDs for them to ensure referential data integrity? How do we know how many orders were created/fulfilled between two API calls if we had two unrelated market transactions? Are these two orders or a single order?
You guys screwed up by not following design principles like the "single responsibility principle" and "separation of concerns". The MarketOrder API call should be self-contained. It should not be required to use other API calls to understand it.
Again, please revert this change asap or provide a solution. Thank you.
Please provide a solution for these problems, some trading tools have now, due to the change of the MarketOrder-API! Yes, I could do workarounds and "approximations", but as a *real* software developer I prefer *clean* solutions. How about an optional parameter for transmitting also cancelled/sold out orders?
|
Thart
U.K.R.A.I.N.E SOLAR FLEET
|
Posted - 2011.06.23 12:40:00 -
[79]
Originally by: Hel O'Ween Edited by: Hel O''Ween on 18/06/2011 13:18:01 I don't like the change to the Market Orders API.
What about the following? You have this nifty little oderState flag in your database/API already. How about adding this as a paramater to the Market Order API query?
This way the dev has control over what data he receives. Those that only need the active orders could just add that parameter to their query. You could even go so far and go with orderState=0 (Active) as the default setting, if the orderState parameter isn't passed along in the query. That way you would benefit from reduced traffic from those apps that are "too lazy" to implement the change.
Parsing through three different APIs (Market Order, Wallet Journal, Wallet Transaction) sounds like a weird thing to do in order to find out which market order has expired and needs to be resupplied by the trader.
Bonus points for adding a parameter for issueDate (return orders issued on issueDate and later)
Signed! ----------------------------------------- EVE Mentat - true trade tool |
Siiee
Recycled Heroes
|
Posted - 2011.06.23 13:43:00 -
[80]
Thirded.
I've been using expired orders to track the most recent price I've payed for a set of items. Without them I can do client side caching but then I still have a chance of missing orders entirely if they get posted and filled between API pulls. I'm going to have to pull a lot more data down to check wallet transactions to get the same data. Think large orders being filled in small increments. Just a handful of mineral orders can fill pages of wallet transactions.
|
|
Desmont McCallock
|
Posted - 2011.06.23 19:17:00 -
[81]
As representative of the EVEMon Dev Team, I would like to inform you that due to the change made in the Market Orders API call, EVEMon can no longer notify the user when an order gets fulfilled or expired (meaning that you managed to remove a key property of the feature).
Therefore on behalf of the EVEMon Dev Team and the EVEMon users, I protest and kindly request that CCP reverts the change.
|
Thebriwan
LUX Uls Xystus
|
Posted - 2011.06.23 22:00:00 -
[82]
I personally am not interested in orders that have been filled, but I can see that traders need that information. But I can also see the problem that arises with the big data volumes that the old system generates.
So I have a proposal to make:
Just make it so that all orders are replied that are outstanding and the filled orders since the last api request for orders.
|
Tonto Auri
Vhero' Multipurpose Corp
|
Posted - 2011.06.24 00:28:00 -
[83]
Quote: we figured most people are calling this to watch their active orders
Oh, wat? I'm absolutely sure, that 100% (yes, 100%, not even a single one left aside) of people, who persistently monitoring their market orders, do so for only one reason: To monitor completed and expired orders. If by some strange reason you would've removed active orders from API, people would've lived with such unpleasant, but somewhat usable information, I think, but as you made it now, you just removed the very reason for existence of this API call.
Quote: We're also quite sure that you'll let us know if we're wrong, as you always so diligently do.
Yeah, we do. You could always trust us in that. -- Thanks CCP for cu |
Thart
U.K.R.A.I.N.E SOLAR FLEET
|
Posted - 2011.06.24 07:02:00 -
[84]
Originally by: Thebriwan Just make it so that all orders are replied that are outstanding and the filled orders since the last api request for orders.
There will be problems with multiple tools used the same API. The better solution is to limit non-active orders in time. One week for instance. ----------------------------------------- EVE Mentat - true trade tool |
SghnDubh
BattleClinic
|
Posted - 2011.06.24 15:17:00 -
[85]
Um, CCP guys.
The API reports every ship type as '0' instead of the correct ship, which makes all KM's sucking through the API malformed.
I'm reporting this here b/c originally we thought we were victimized by this "forcing you pesky 3rd party devs to optimize your code as if you were huge corporations with tonnes of programmers on staff" blocking scheme. Ok that was maybe harsh but I'm posting on eve-o, aren't I? :D
So, we need some API love QUICKLY please!!!
.
Timecodes: http://shop.BattleClinic.com
|
Gambit Ki
|
Posted - 2011.06.27 04:50:00 -
[86]
Edited by: Gambit Ki on 27/06/2011 04:50:33 I would also like to ask that the MarketOrders data be fixed. As many others have pointed out the filled order data is important when managed 150+ orders. Try scrolling through your order trying to find what has sold out.
I thought local caching might work but it is true that short sales may not show up inside the 1 hour window making the tracking a guess at best.
Please bring back the different orderStates even if you limit how much data is returned. I'm happy to cache as long as I get the correct data.
Thank you
|
Melina Octurian
101st Space Marine Force Nulli Secunda
|
Posted - 2011.06.27 06:57:00 -
[87]
My trade team seeds 400+ orders on behalf of corporation, and it is nearly impossible to determine if a particular order has expired/fulfilled unless we go line item by line item. Additionally, 3rd party API programs (such as EVEmon) are not showing corp orders.. only personal orders. A resolution on this matter would be greatly appreciated.
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.06.27 10:02:00 -
[88]
Edited by: CCP Elerhino on 27/06/2011 10:03:04 We've been looking into the MarketOrder issue but finding a solution that is both simple and optimal has proven difficult. The reason is the nature of market orders, specifically how dates are stored and how they change and how the data can be retrieved in a cost-effective way. Basically us API people are arguing for simple but the DB team understandably wants optimal. Right now it looks like we'll do paging, something like the wallet transaction API, we hope that will solve the problem even though it might cost you guys some extra work. I was hoping for something simpler, e.g. include a week or a month of expired orders in the list but, like I wrote, that solution is not optimal from a DB standpoint. We'll get a solution ready as soon as possible, hopefully within the next few weeks.
The shipType defect has been fixed, we'll deploy that this week. The defect was only in the API layer, the data is correct in the database and will be displayed correctly for older kills in the API after the fix is deployed so you will be able to correct the 0-values that you already have.
CCP Elerhino CCP Software - API
|
|
Gambit Ki
|
Posted - 2011.06.27 14:49:00 -
[89]
Thank you for your response. Paging would work just fine. It's not really that hard to crawl transactions and merge the results to a long list.
|
Melina Octurian
101st Space Marine Force Nulli Secunda
|
Posted - 2011.06.27 19:54:00 -
[90]
Originally by: CCP Elerhino Edited by: CCP Elerhino on 27/06/2011 10:03:04 We've been looking into the MarketOrder issue but finding a solution that is both simple and optimal has proven difficult. The reason is the nature of market orders, specifically how dates are stored and how they change and how the data can be retrieved in a cost-effective way. Basically us API people are arguing for simple but the DB team understandably wants optimal. Right now it looks like we'll do paging, something like the wallet transaction API, we hope that will solve the problem even though it might cost you guys some extra work. I was hoping for something simpler, e.g. include a week or a month of expired orders in the list but, like I wrote, that solution is not optimal from a DB standpoint. We'll get a solution ready as soon as possible, hopefully within the next few weeks.
Thanks for the response. I undoubtedly understand the need to slim down the DB storage and volume of data sent with API calls. However, I'm sure that a compromise can be struck in this regard. In terms of the market seed API calls, I think most active traders don't even need a full week of expired orders to be backlogged. Also, is there that much need for API data to be sent more frequently than hourly? I'm not very knowledgeable regarding the frequency of data sent, but would limiting said frequency possibly work toward that "optimal" solution you mentioned?
|
|
Major Stallion
The Dark Horses.
|
Posted - 2011.06.29 06:46:00 -
[91]
My market API hasnt functioned correctly since Incarna 1.0. Can anyone shed light on why my market information is refusing to update in evemon and other related software? It's still showing orders from pre-incarna that have long sold out.
Im literally ******ed when it comes to API speak, so simple terms would be best.
|
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.06.29 16:32:00 -
[92]
I explained it here.
As EVEMon and other apps were built when all order states were available through the API, they stopped functioning in that regard as they can now longer compared new order state from current API data to old order state on file. -- EVEWalletAware - an offline wallet manager |
Mark Fujita
|
Posted - 2011.07.01 17:08:00 -
[93]
Originally by: Desmont McCallock As representative of the EVEMon Dev Team, I would like to inform you that due to the change made in the Market Orders API call, EVEMon can no longer notify the user when an order gets fulfilled or expired (meaning that you managed to remove a key property of the feature).
Therefore on behalf of the EVEMon Dev Team and the EVEMon users, I protest and kindly request that CCP reverts the change.
Evemon user here, and i agree with the quoted text. I protest as well!
|
ColnelPanic
|
Posted - 2011.07.10 11:21:00 -
[94]
Do we have a more concrete estimate then 'within the next few weeks'. I am sure all the developers would appreciate some date to work towards to and details on how to?
Would make the issue go away faster so i can use it again :)
Originally by: CCP Elerhino Edited by: CCP Elerhino on 27/06/2011 10:03:04 We've been looking into the MarketOrder issue but finding a solution that is both simple and optimal has proven difficult. The reason is the nature of market orders, specifically how dates are stored and how they change and how the data can be retrieved in a cost-effective way. Basically us API people are arguing for simple but the DB team understandably wants optimal. Right now it looks like we'll do paging, something like the wallet transaction API, we hope that will solve the problem even though it might cost you guys some extra work. I was hoping for something simpler, e.g. include a week or a month of expired orders in the list but, like I wrote, that solution is not optimal from a DB standpoint. We'll get a solution ready as soon as possible, hopefully within the next few weeks.
The shipType defect has been fixed, we'll deploy that this week. The defect was only in the API layer, the data is correct in the database and will be displayed correctly for older kills in the API after the fix is deployed so you will be able to correct the 0-values that you already have.
|
Vinni Starseeker
|
Posted - 2011.07.12 06:54:00 -
[95]
Originally by: Mark Fujita
Originally by: Desmont McCallock As representative of the EVEMon Dev Team, I would like to inform you that due to the change made in the Market Orders API call, EVEMon can no longer notify the user when an order gets fulfilled or expired (meaning that you managed to remove a key property of the feature).
Therefore on behalf of the EVEMon Dev Team and the EVEMon users, I protest and kindly request that CCP reverts the change.
Evemon user here, and i agree with the quoted text. I protest as well!
Another EveMon user here and I'd like to add my support for re-introducing the listing of expired orders. I maintain over 200 market orders and having details of previously paid prices is really important to my trading.
|
Callean Drevus
Caldari Icosahedron Crafts and Shipping Silent Infinity
|
Posted - 2011.07.20 12:45:00 -
[96]
I would like to repeat, that the market order API is still pretty useless. When will this problem be fixed?
Just my 2 cents, but I honestly do not understand why you try to fix things that ARE NOT BROKEN. --- "A fool flatters himself, a wise man flatters the fool."
Co-founder of NEMIA. |
|
|
|
Pages: 1 2 3 4 :: [one page] |