|
Author |
Thread Statistics | Show CCP posts - 37 post(s) |
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.07.22 14:50:00 -
[1]
Just thought I'd put it out here since you ask people to start testing that I'm in the process of converting Yapeal to use the new keys and should be able to start testing within a couple weeks if things go as planned.
Quote: We will give sufficient warning before we turn off old-style keys. But once we ship the new system, you will be unable to create any more old-style keys.
I'm with Fade Toblack on this there should be at least a short (couple weeks to month) period when both types can be created and say 3-6 month period when both style keys work with the APIs so that people that are just starting with Eve and those that have been away from it due to RL aren't left in the dark without chance to use the many applications that have been built up around the APIs while they move from the old system to the new. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.07.23 05:17:00 -
[2]
I've just been looking at the new calllist.xml.aspx API and noticed that there are two rows with name="CharacterInfo". Could they maybe be named name="CharacterInfoPublic" and name="CharacterInfoPrivate" or something as it's confusing with them both having the same name. I notice that in the key creation page to and think it's going to be confusing there as well without some way to separate them beyond the group they are in. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.07.24 05:22:00 -
[3]
I've been trying some things with the APIs and thought I'd share what I've found and make a sugestion on a change to account/APIKeyInfo.xml.aspx which would be useful.
First something I've notice is none of the corp APIs now need characterID which makes sense since all corporation type keys are per character unlike the old ones.
If you use a single character key with char APIs you also don't have to use characterID with them but if you use one made to work for all characters you do have to include characterID parameter in the query so API knows which one you want.
Given the above and the fact that multiple corp keys don't really make sense when you think about it I think it would be nice if the type attribute in APIKeyInfo would return "All", "Character", or "Corporation" instead of just "Character", "Corporation". Could that be done? I think it would be an easy change to make server side and could greatly simplify parsing and using it in applications because there really are three types of keys now and they may need different handling at times.
Anyway thought I'd share the above and see what everyone else thinks. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.07.26 03:50:00 -
[4]
Ok with another day of work with APIKeyInfo and the different types of keys I've got a couple more suggestions on changes. The single character keys work find as is with the API as is but corporation and all characters keys aren't as friendly to work with. The corp keys you can work around by using 2 API calls one to APIKeyInfo and another to account/Characters as well so you have the info needed to map from characterID to corporationID but I think there is a better way which I'll get to shortly. The real problem is with all character keys. If you are doing like I do in Yapeal and storing the data directly to a database table which is storing info for multiple accounts you have no way of knowing which characters they belong to. Now for libraries that are single account/char/corp based it's probably no problem as they know all the characters they are working with in Characters can use the key but I think they will also run into some problems when it comes time to save the data that I'm having to face up front.
Now for a simple way to solve the need for 2 API calls for corp keys is to instead of return the characterID return the corporationID directly instead. The type attribute could even be dropped I believe but it could stay.
Now how to deal with all keys isn't so simple. One way would be to add another attribute called something like characterIDs. If this was done I would say type really should be dropped as it no longer useful. It would probably be a good idea to have the attributes that are empty not appear in the XML but the idea of three optional attributes like that is at best just messy.
Another idea would be to have a single attribute named just IDs and have type do it's job with the addition of an "all" or "multiple" option much like what I proposed the other day.
There is one other idea as well which I've decided should be looked at too. I was one of many voices at the start calling for something like the all character keys but I can see the reason the new custom key system originally was proposed without them and just had single character and single corporation keys. It makes for much simpler key management in applications, libraries and I'm sure on the servers as well. It would also simplify calls to char APIs as now if you use all character keys you also have to include the charID so the API knows which one to return the data for. With just single character keys that isn't needed and all the account, char, and corp APIs would be the same and just have keyID and vCode as required parameters.
I believe now is the time to look at making this change while all the third party developers are in the early stages of changing things in their software and the code is still fairly fluid in CCP as well. Anyway I look forward to some feedback from both CCP and another developers on my ideas or maybe someone will have a better idea that solve everything in much cleaner way. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.07.30 14:20:00 -
[5]
I like everyone else have been thinking on the old two key system vs the new custom key one that is coming. I'm sure in one form or another we all used some way of associating userID to APIKeys and from there to the characters and corporations. So we all had some like userID[1] -> APIKeys[2] -> characters[3] -> corporations[3] but now there are currently 3 types of keys with three different associations. keyID[x] -> character[1] keyID[x] -> corporation[1] keyID[x] -> characters[1-3] For most libraries/applications 'x' is one but there is no reason it has to be except it makes it easier for us as developers and for our users to administrate the keys. There is a userID (accountID) indirect relationship too still but it only has some meaning in the last case and is very weak. Now what I found useful while trying to decide what needs to be changed in my code is to think about the last case but with 'x' equal to number of APIs in the mask and how I'd have to change things to make that possible and how it would work.
Since I'm using a database to store the relationships I'm going to end up with a key table for all the keys, a character table for all the chars, a corporation table for the corps, and one or more tables to link the keys with the characters and corporations. It really will be easier to work with in the end because of the shorter relationship tree but it will take a lot of work on my part to remove the old implied two key relationships that were in my code.
Hopeful some of you will find the above useful in understanding the problem and it will help clarify your thinking like it did for me and lead you to the changes you'll needed to make. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.07.30 15:44:00 -
[6]
Quote: Personally, I think "userID" will be redundant with CAK system but it could though be renamed to "accountID".
That would work for me and better describe what it is now. It would also help maybe keep from confusing old info on the API with the new for people when trying to learn more about the APIs.
Quote: With CAK system, it will not be possible to do calls to Character related calls if you have the API key issued for Corporation use (if I'm mistaken you can discard the following lines).
I understand where you're coming from on this one but as I stated in the above post if you really start thinking about and changing things to work with multiple keys it a much more flexible system which of course is part of the problem It will require managing more than one key especially if you do want to monitor more than one corp but for most people with one account they should only need two keys, one for all chars and another for a corp. Even in my case with a couple accounts I'd only need like four keys, 2 * all chars, 1 for main corp and another for alt corp since all my chars are in only 3 corps and one is in an inactive corp I don't monitor. That is of course if I decided to use the new stuff you've been adding to EveMon which I not really now since I'm usually running Linux and use Gtkevemon Mind you I was thinking of both applications as well is my own project when I asked for a single key for all the characters on an account but now I'm leaning more to not having that but just single char and corp keys because it is a much cleaner system to work with if a bit more complex to admin.
Quote: I no longer see a way to tell the difference of a key for an account that has one character on it or restricted to show one character. This will either force corporations to require all character slots are full for recruitment and/or screenshots of character selection.
I'm with Johnathan on this we need a way to tell. There's lot of work for all the developers both inside and outside CCP being done and there are so many great things about the API changes being made it would be a pity if this issue ends up leaving an overall bad taste in all of the third party developers' mouths because we have to take flack from our end users on this regression. It would be very easy to solve by simple having the type not just return 'character' or 'corporation but 'multiple' or 'all' as well in APIKeyInfo for all character keys. I know you have to have some way to tell them apart internally at CCP to have the character APIs require us to include characterID parameter when using them.
Quote: PS. I want an employment history API, its in evegate in a very tempting format to sc****
This would be nice and be one more step along the path you've already started on to make public info you can get in the game also through the API.
One bug I've noticed is when I go to edit one of my keys it always fills in the Verification Code with a new random value instead of pre-filling with the old value. This kind of makes the generate key link worthless IMHO anyway On creating a new key pre-filling with a new random code would probably be good but not when trying to update it. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.01 15:32:00 -
[7]
So I thought of something while looking at the XML for APIKeyInfo to make a new XSD schema for it. With all the changes from custom keys and added APIs etc shouldn't the version on <eveapi version="2"> be changed to '3'? It probably could have been changed before now but with as big of change as custom keys is I think it's important to reflect that in the version. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.02 15:40:00 -
[8]
I did some quick math let us look at doing combined keys masks. The char/account key currently uses 26 bits and corp uses 23 bits which with a 64 bit mask would leave only 15 bits or to put it another way there could only be 15 more APIs added between all 3 of the API types. There also is the issue with signed vs unsigned integer so to not have problems there you end up with 14 APIs more. A 128 bit mask is possible but even most DBs don't work well with them and a lot of programming languages already can have problems with 64 bits on 32 bit OS.
Now let us look at doing things without any combined keys. Char/account currently uses 26 bits leaving 5(signed)/6(unsigned) more with 32 bit and 37/38 with 64 bit. Corp would have 8/9 with 32 bit and 40/41 with 64 bit.
So to sum up in the short run combined keys makes the conversion easier for us as third parties but since CCP has already spent the time on their end going to other way in their design it'll come back to bite you once they have a need to expand beyond what they allow. Just think if we ever get alliance APIs or something else how limited it would end up being. Believe me I feel your pain as I'm running into several problem myself moving to a multiple key system but I know in the end it'll work long into the future no matter what changes in the APIs too. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.06 06:37:00 -
[9]
I see a couple people asking that the access mask include something to say if it's a single or multiple char key but that's not the way to do it IMHO anyway. It makes much more sense to have type have one (or more) additional values. If it was added to mask you'd have to check 2 things to figure out what 'type' of key you have which just doesn't make sense at all. Having type return 'Character', Characters', 'Corporation', etc is much more logical and leaves more room to expand on key types and new APIs without needing to go to larger bitmap for access mask.
As I've already stated and others have as well if there isn't a way to tell if a key is telling the 'true' about how many characters are on a account than it will have failed in a very large way. I'm fine with it just letting people know there are other characters which the above would do and let the parties involved work it out if a multiple character key is going to be required or given. I just don't see why this even needed to come up really because how could anyone at CCP thought it would be accepted by anyone to take away something that has existed every since the APIs came out. It just isn't going to be accepted by any of the developers or the player base either. CCP is really out of touch with everyone else on this. I know there isn't any technical reason for it since the webpage where you can view your keys already shows under the character column 'all' for them so not providing the same information in the API is just ridiculous. |
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.07 15:47:00 -
[10]
Quote: Another thought, would it be possible to include a 'Copy to Clipboard' button on the API Key Request page that copies a well-formed XML fragment the user can paste to the requesting third-party app to be parsed?
The only thing they should have to copy for anyone else are the ID (KeyID) and Verification Code (vCode) and then you get to do the work via the API in your application. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.12 04:01:00 -
[11]
Just wanted to say thanks for the update to APKeyInfo so type now returns account, character, corporation that will make things much better.
The employment history on CharacterInfo is cool too even if Johnathan Roark ended up hurting his back over it -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.22 16:53:00 -
[12]
I'll agree with Desmont McCallock that the first couple points need fixed as I'm sure they will be but on the last couple I have a bit different view.
Quote: Issue: APIKeyInfo call returned data includes the data returned from the Characters call, making the Characters call reduntant. Possible Solution: Merging the APIKeyInfo data into Characters call (after all they have the same restriction level) and remove the APIKeyInfo call.
I'd go the other way and merge Characters into APIKeyInfo and have in Yapeal already. Gets us to the same point and the API name makes more sense with the additional function it serves now.
Quote: Issue: With the possibility of an account having multiple API keys (with various accesibility to API calls) a way to bound those keys to the account is necessary.
Not in the APIs though as they all work without it. I think if there weren't any 'Account' keys more people would see their way to better options but I'll give it a try in guiding you to how I've started viewing how to handle this. I'll try to put this as clearly as I can without making this post to long which I've been known to do What you are calling a accountID also known as userID by the old was limited and what you really need is a groupID for lack of something better to call it. What does a groupID do? It allows you to collect a bunch of keys for chars/corps so you can manage them. The group will be associated with a single RL person which for most web applications has a signin name etc but in non-web application doesn't usually have any since most desktop Eve applications are really single user. Now how does this help? Well you now can say group all of you manufacturing chars into a group, miners into group, all your PvP chars together in another, and your CEOs/Directors alts say into a different group and have settings that reflect their function and what you want to do with them without worrying about which 'account' they are on. There is even the option to have the same char be in more than one group if you use them for different things.
Notice how everything is about the chars just like the APIs keys are now but you can still manage them together as you need. You can do the same with corporations too. Say you have a couple of login accounts in Eve and have 6 chars. Lets say 2 char on the one account belong to corps in an alliance and maybe one on the other one is too. Lets say they are all CEOs or directors in the corps and you need to do some alliance business like do some kind of end of month report by using groups you can have a view on say the IndustryJobs that highlights just the ones dealing with the new Outpost you're building or a marketing group so you can do a report on how sales have been going in a region.
Hopefully this gives you some other ideas how NOT have an accountID in the API can be an advantage as now you can group things as you want to not as CCP would force you to do. You just associate the keys with the chars/corps as given in the APIs and then associate them how you or the users thinks makes sense. I'm out of time but hope this helps you see things in a different light and give you another direction to approach the problem. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.25 04:43:00 -
[13]
I've been using the default 5 minute cachedUntil with 3 overlapping keys with 2-3 chars per account key and not ran into problems in testing so I don't foresee it being to much of a problem being banned.If you are worried about it you can try using a longer cache time as the info shouldn't be changing that often really. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.27 04:57:00 -
[14]
It's just been brought to my attention something that is very puzzling and got to be an error. We have some APIs with more than one bit in the accessMask and all the APIs having at least one bit with the exception of APIKeyInfo and accountCharacters where it makes sense not to have one.
Now what is puzzling is how the contract APIs ending up with only one when even dependent APIs for Starbases (POS), Mail, etc all get their own? This just doesn't make any sense at all. The total lack of consistence here I can't understand really. Now I'll have to say for my part why I didn't notice it before I don't know and I'll take some of the blame for not noticing sooner and saying something about it but how did this get missed by everyone at CCP and all the third party developers? I don't know about anyone else but with how Yapeal works this is going to cause a lot of problems and really is an error as far as I'm concerned and needs to be fixed even if it might delay contract API to do so and not have the contract APIs available with patch launch next Tuesday.
I know Johnathan Roark post something about this in the contract API thread as well. He was the one that brought it to my attention with a question about how it would work in Yapeal. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.29 02:13:00 -
[15]
They will have to get a new key from a director or the CEO no other way now. The good thing is the key only has to give them the access they need now and they only get access to corp info and not also all the personal info of whomever gives them the key. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.09.01 04:46:00 -
[16]
Quote: On sort of that topic the Create API key needs presets(limited API) or additional information. The question mark towards brings up API information on what is given which isn't detailed enough. APIs specific to information that used to be under the Full Access API like the wallet should have a warning on them and state things like the application or players with this key can see everything you do in terms of buying/selling/etc. Them seeing the XML results is pointless. Plus some may just not understand it and basically start using Full API data for everything. It's easier to click All in each section than it is to understand what I'm actually selecting. It's just opening up for abuse in a sense from people tricking others into getting what used to be the Full Access API key.
Just had to comment on this. Your right but this is kind of like with warning before entering low sec most people are just going to ignore or not understand it and jump through anyway and until they've had their ship blown up they don't understand most of them. I bet if you did a poll most Eve players have to go through that before they truly understand what's going on. I did it myself I know and I had a couple friends that had been playing Eve for a while warning me as well not to go into low sec or I'd end up losing my ship at least For most people the only way they can learn is by making the mistake themselves then they pay attention when only a rare few can learn from seeing or hearing about others mistakes. Anyway that's my 0.02 ISK on it -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.09.04 17:03:00 -
[17]
Quote: I'm not sure if this is intended, since it's an Account query and not a character, but that makes me wonder why you even allow for a character ID to be sent with the account if you aren't going to use it.
Actually all the APIs seem to ignore any parameters they don't understand which is what you are probably noticing. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.09.06 14:35:00 -
[18]
Make sure you aren't trying to use any test server keys on main server or the other way around as I believe you get that error in both cases. |
|
|
|