As the EVE-Central front end evolves, I am dropping support for all Internet Explorer versions prior to IE9. Its just not reasonable for a single person development team with only a few hours per month to dedicate to support IE’s broken functionality, especially on an outdated operating system.
If you still want to use Windows XP, I strongly suggest moving to Chrome or Firefox.
EVE-Central has a new sponsor: EVETimeCode. If you’re considering buying time codes for game time or conversion to PLEX, please consider purchasing from our sponsor. They keep the lights on and the servers running.
Hosting costs are expensive, and we move through terabytes of bandwidth per month in order to keep our services up and running.
Effective August 15th, we will be closing the EVE-Central SMTP market push service (http://dev.eve-central.com/evec-api/start#mail_smtp_push).
While the SMTP service has reliably been trucking since 2006, better things have come and made the SMTP service seem like a rusty wheel. Specifically the EVE Market Data Relay: http://eve-market-data-relay.readthedocs.org/en/latest/index.html. I advise everyone currently using the SMTP service to migrate to EMDR as soon as possible.
Currently, the SMTP push service is consuming over 1TB of transfer per month. EMDR is more modern and more efficient.
As part of the migration to EMDR, we will consolidate all of our classic client traffic to relay to EMDR.
The new API and upload processing backend, anyway.
To start, I moved all of the existing API documentation to the EVE-Central Wiki. You can find documentation (with less typos, etc) here:
Next up, I’d like to highlight two new APIs:
quicklook on path
For a single market type, get all of the orders which lie on a path between two systems.
Get the route between two systems as the auto-pilot flies (mostly, kinda)
You’ll notice that the route API is returning JSON. I will be upgrading the other APIs to emit both XML and JSON for convenience.
The EVE-Central API service was refactored on top of a new framework, both as an aid to scale (for performance reasons), and an exercise in using new tools for web development. Except for a few growing pains, the stack has been reliable and performant.
The bits and pieces that made this possible:
- Scala – A static typed JVM-targeted language with a very good mix of functional programming. Often compared to OCaml and F#, where it shares a lot of similarity. The JVM platform gives a lot of run time performance and a huge software library, but the Java language is hobbled by years of mismanagement (see C# for something not hobbled by Sun). Enter Scala – fast, type safe, expressive, and generally fun to work in. (I still love Python too, for those of you keeping score).
- Akka – an Actor system framework, with lots of inspiration taken from Erlang (great ideas, mediocre execution). Its a message-passing system built for the JVM. While we are still using Akka 1.3, the new clustering capabilities of Akka 2+ are on my radar.
- Spray-server and Spray-can – Spray server is a Scala and Akka library for building web services, in a clean and no-nonsense fashion. Spray-can is the HTTP server component, avoiding the use of a traditional Java servlet container for managing connections. If you’re looking for a way to make RESTful (and non-RESTful) webservices in a high performance environment, give Spray a look. The community support is great.
Note that this is just the old API. No new (published) API calls are available yet, but with the speed gained by building a proper framework around some of the core technology of EVE marketing aggregating, and the inherent testability of the environment, new features should be significantly easier to bring to light.
Also, the EVE-Central user front end remains on the old Python+CherryPy stack for the time being, as the window dressing is being worked on.
New faction/deadspace types, and name changes.
I have just updated the servers used for the EVE-Central API calls. As DNS updates propagate, you will be running on a new stack which funnels requests between the old and new servers.
If you have any serious API issues, please let me know as soon as possible.
If you are NOT using the api.eve-central.com domain name for API calls, API calls may start to fail in the near future. Consider this your “its been two years since this change was made” deprecation warning.
I would like to reach out and find a few users of the existing EVE-Central API in order to perform regression tests against the new API service. If your website or application uses the API and you would be willing to test under a new URL, please let me know (comments, e-mail, eve mail). I will provide you with the URL to use.
The API should be identical from a usage and formatting standpoint – it simply contains a brand new backend, statistics engine and cache layer, implemented in Scala. This is not the “v3″ API, simply a reimplementation of the old one.
I had intended to launch this about a month ago, and make a nice post about the technical design, but well thats what happens when you run out of time
After a test period by the EVE-Central Google Group members, I am pleased to announce Contribtastic 2.1.1 for EVE-Central. Contribtastic is our cache-scanning no-nonsense upload client.
New in this version:
- Automatic cache folder detection! Everything happens under the hood, including when the EVE client updates
- Multiple client support! Multiple EVE clients are now detected and managed automatically.
- New icons
- Application remembers its tray status – it will relaunch to tray only if it was last hidden in the tray
- Little bug fixes
Get it from the software download page.