Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

End of Life #59

Open
Bleyddyn opened this issue Jan 3, 2018 · 1 comment
Open

End of Life #59

Bleyddyn opened this issue Jan 3, 2018 · 1 comment

Comments

@Bleyddyn
Copy link
Collaborator

Bleyddyn commented Jan 3, 2018

Vitality will almost certainly stop working as of May 8th, 2018. For a brief explanation of why and for links to more detailed information check out this Third Party Developer Blog from CCP.

EVE Online has had at least three entirely different and incompatible API systems:

  • XML API - the oldest of the three, largely supported by Vitality
  • CREST - the middle child. Not at all supported by Vitality
  • ESI - the latest and greatest. Again, no support by Vitality

The problem with both the CREST and ESI API's is that they require a developer key to be embedded in the application. This means that an enterprising user could extract the key and pretend to be that developer for nefarious purposes. I am not willing to risk that and as far as I know, there is no way around it. Most of the example code I've seen assumes a web application where the developer key would remain safely on the server, not accessible to users.

I have been the only person working on Vitality for a couple of years now. Given how little I've been playing EVE and the abov
e problem I don't think I'll be working on switching Vitality to use ESI.

Vitality has no tracking code so there's no way to know how many people use it, nor is there any reasonable way to contact people who do. So I have no idea how many people this will impact. If there are enough people who still use Vitality, then there's a chance that one or more of them will step forward and keep it going. One of the few good points is that most of the XML API specific code is at least reasonably well hidden behind classes which should minimize the amount of code that needs to be changed, as long as ESI really does cover all the same functionality as the XML API.

@ryanniccolls
Copy link

Thank you for maintaining thus far. Good luck in your future endeavors.

All the best.

Ryan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants