EVE Technology Lab

I just discovered the whole API CAK subject and can say that after 40 years of computer software experience I can guarantee that 31 to 32 keys defined in the access mask is not enough. Oh sure when the 31th is defined implementation of the 32nd will be delayed before making the thing negative and then there will be a big delay with reusing old bits before the next feature is implemented, but it will happen. So a year or two from now, if we are lucky, we will have to all go through this again, a 64 bit mask, two 32 bit masks, or whatever. The reality of the char/corp usage of overlapping bits might should have illustrated this. When the question of combining both char and corp permissions into one mask was asked, it resulted in complaints that 32 bits would not be enough, and the handwriting was on the wall for EVE API future.

So what is the real problem? The whole bit mask thing is exposing an internal EVE API structure that should never have been exposed. How the EVE API handles what permissions goes with what keyID/vCode is basically an internal issue to their software. Their API software can probably be changed to extend this to 64 bits quite easily, but the ramifications propagated throughout the entire EVE API community (App Developers and Users) will be major. So while the EVE API community is currently making modifications to their code sets, I am going to suggest a major change. The number of permissions that can be associated with the CAK should be infinite. The following change is what I would suggest be made to the APIKeyInfo results:

Assume { = < and } = >

{?xml version='1.0' encoding='UTF-8'?}
{eveapi version="3"}
{currentTime}2011-09-10 14:41:29{/currentTime}
{result}
{key type="Account" expires="2011-09-11 00:00:00"}
{rowset name="permissions" key="permission" columns="permission"}
{row permission="CharCharacterSheet" /}
{row permission="CharContracts" /}
{row permission="CharResearch" /}
{row permission="CorpContracts" /}
{/rowset}
{rowset name="characters" key="characterID" columns="characterID,characterName,corporationID,corporationName"}
{row characterID="898901870" characterName="Desmont McCallock" corporationID="1000009" corporationName="Caldari Provisions" /}
{/rowset}
{/key}
{/result}
{cachedUntil}2011-09-10 14:46:29{/cachedUntil}
{/eveapi}

Ok, pretty obvious that the requested keyID/vCode can do the following calls: /char/CharacterSheet.xml, /char/Contracts.xml, /char/Research.xml and /corp/Contracts.xml.

How do you use this in a program? Well multiple ways, build your own bit mask with the permissions you want or are concerned with and ignore the others. Define a mysql table with characterID and permission as the SQL key to see if a given keyID can access a given API call. The important thing is that it would be flexible for today and expandable for the future.