ANN: The next few steps for EMDR

[Gregory Taylor]

Thanks for all of the responses to our earlier thread about what to do with EMDR in the upcoming CREST-market-data era. That was exactly what we were looking for.

From what I've heard, there's still value in a CREST-driven EMDR. It's still much easier and potentially more efficient for most to get their data fed to them over EMDR. We'll go into the rationale behind that soon. The big thing I wanted to make sure we all knew is:

EMDR will continue operating, and no changes will be necessary for current consumers with proper UUDIF implementations. The only thing that will change is when the new market CREST market data APIs land, we'll switch over transparently and you'll start receiving pure, accurate data. You won't need to do any validation anymore, unless you want to.

Now, why would anyone want to use EMDR, now that we can all poll for ourselves?

• Polling can be resource-heavy. The HTTP request/response cycle isn't a light operation. If responses hang or slow, you can end up in a world of hurt unless you have designed your poller correctly.
• Why re-invent the wheel? We'll be working on an API scraper together that will power EMDR and other sites like EVE Central that *have* to have ridiculous resolution.
• You won't ever have to worry about rate limits. If the limits get cranked down as the market data API becomes generally available, we have a few ways to guarantee that you'll continue to receive things quickly.
• Right now you need an active account to use the CREST API. CCP has already said they want to remove this limitation, but I don't know of any timeline for this. EMDR fill feed everyone, without API keys.

There are probably more benefits, but these are the major ones.

We have started tinkering with potential scraper arrangements, and will have more on that as things develop. We'll be in touch!

[Aebe Amraen]

Just to make sure you're aware--all market data is already available on CREST, both historical (public CREST) and live (authed CREST, 5 minute cache).

Aebe