| Pages: [1] :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Sentient Blade
   |
Posted - 2011.05.30 03:37:00 -
[1]
Hi,
I am just getting into the API and I am somewhat puzzled by the operation of the member tracking API listed on http://wiki.eve-id.net/APIv2_Corp_MemberTracking_XML.
The problem I am facing is that I think it is possible to encounter a race condition when independently updating two separate datasets when considering the caching. I suspect this may be the case in multiple parts of the API however I am just starting off.
I have local tables for characters, corporations and corporation members and I am seeking to update the corporation members list as frequently as would be permitted from the API. I have implemented a full local cache of received data which issues a new request when the timing allows.
Now, if I were to attempt to lookup the members lift of a corporation, I would execute a call to MemberTracking.xml.aspx giving the character ID of a director of the corporation I wish to load.
Considering the caching delay between a character being updated (ex: leaving a corp and changing corpID) and the cache next allowing my local data to be updated, how can I be sure that the member list that I am receiving relates to the corp that I am trying to update, and not to a corp which the character has transferred to in the period between the last update of that character and the request for a member list?
I was hypothesising that I could perhaps test each of the members, hope at least one of them was not cached and validate the corporationID that way, however this would seem somewhat improper and likely to introduce other errors.
The entire mechanism seems strange to me, for such a call I would expect to see a corporationID parameter given in addition to characterID, or no characterID at all.
Could someone please advise? Failing this would it be possible to have corporationID added as a text node to the result?
Cheers.
|
Peter Powers
FinFleet
Raiden.
|
Posted - 2011.05.30 05:33:00 -
[2]
First of all, where is your director information comming from that you use for that request?
a character has to drop roles and wait 24 hours before he can leave the corp, so he will not be marked as as director for the old corp, and still be in a new unknown corp. However that might not be the case for a single ceo leaving his own corp.
now what you could do is deciding on when / when not to trust the cached data by reading the startdatetime field of the character that you used to pull the data, and working with that through the cachetimers.
Deblob! the Website with Statistics about the BFF vs. DRF+Friends. Conflict!
|
Lutz Major
|
Posted - 2011.05.30 08:01:00 -
[3]
 Originally by: Sentient Blade
Considering the caching delay between a character being updated (ex: leaving a corp and changing corpID) and the cache next allowing my local data to be updated, how can I be sure that the member list that I am receiving relates to the corp that I am trying to update, and not to a corp which the character has transferred to in the period between the last update of that character and the request for a member list?
1) what Peter Powers said
2) for determining the correct corp <-> member tracking issue: the corp you query is the same corp as the CharacterSheet states for the pilot!
3) if you still can query the API of a member, who dropped out of your corp then shame on him (in case he becomes a CEO: SPY ON HIM!)
|
Sentient Blade
|
Posted - 2011.05.30 12:48:00 -
[4]
Originally by: Peter Powers
a character has to drop roles and wait 24 hours before he can leave the corp, so he will not be marked as as director for the old corp, and still be in a new unknown corp.
Ah yes, the 24 hour wait! So I can combine a within-24 hour latest update with an NPC member list error condition, it seems strange, but I think that should work.
Regarding where the data is coming from I have added a nominatedAuthCharacter to my corporations tab where one of the directors is selected from a drop-down. Their API key will be used for updating the members list.
It's my intent to create a secure environment where players may enter their full API and then claim ownership of it via either an EvE Mail or small donation payment (using the donation reason field to enter an ID number) and then allow the confirmed owner to share modular information without having to ever hand over their full API, such as providing an option of allowing the directors of their alliances executor corp to always see their skills.
|
Lutz Major
|
Posted - 2011.05.30 13:24:00 -
[5]
Originally by: Sentient Blade
It's my intent to create a secure environment where players may enter their full API and then claim ownership of it via either an EvE Mail or small donation payment (using the donation reason field to enter an ID number) and then allow the confirmed owner to share modular information without having to ever hand over their full API, such as providing an option of allowing the directors of their alliances executor corp to always see their skills.
You mean something like customizable api keys?
|
Sentient Blade
|
Posted - 2011.05.30 13:44:00 -
[6]
Originally by: Lutz Major
Originally by: Sentient Blade
It's my intent to create a secure environment where players may enter their full API and then claim ownership of it via either an EvE Mail or small donation payment (using the donation reason field to enter an ID number) and then allow the confirmed owner to share modular information without having to ever hand over their full API, such as providing an option of allowing the directors of their alliances executor corp to always see their skills.
You mean something like customizable api keys?
Similar yes, but I'm after more of a context sensitive tool with permissions based on rules rather than key knowledge.
|
Peter Powers
FinFleet
Raiden.
|
Posted - 2011.05.30 22:57:00 -
[7]
there used to be someone who had what you are describing,
but the problem was user acceptance, so he stopped doing it.
a while ago a few friends and i started working on a project that would do even a bit more than that, but when the ccp guys promised us customizeable api keys we put it on ice (so we had time working on kingboard instead)
either way, good luck with your try on it, and keep us in the loop where your getting to (hey, why dont you join #eve-dev on irc.coldfront.net, lots of 3rd party guys there)
Deblob! the Website with Statistics about the BFF vs. DRF+Friends. Conflict!
|
Hel O'Ween
Men On A Mission
EVE Trade Consortium
|
Posted - 2011.05.31 09:16:00 -
[8]
Edited by: Hel O''Ween on 31/05/2011 09:16:33
Originally by: Peter Powers
there used to be someone who had what you are describing,
but the problem was user acceptance, so he stopped doing it.
TornSoul (BIG) still seems to run BLEEP, which is the closest we have at the moment, as far as I know.
--
EVEWalletAware - an offline wallet manager |
Peter Powers
FinFleet
Raiden.
|
Posted - 2011.05.31 15:15:00 -
[9]
well, i was speaking of IxForres Gatekeeper...
i don't trust TornSoul further than i can throw a car. (which is not really far)
Deblob! the Website with Statistics about the BFF vs. DRF+Friends. Conflict!
|
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |