EVE Technology Lab

So when can I get this kind of functionality for Dust514? why you gotta taunt us like this?

There are *significant* hurdles in the way of applying this technology to Eve in general. The tournament provides us a very bounded environment - 15 minutes max, 24 ships max, constrained location - which makes this sort of thing possible.

no the game data for your current pvp engagement couldnt be streamed in real time as the crest system has no way of knowing what pvp engagement your talking about.

What id like them to do however, is save the incoming stream of data pre tick that your client receives, and be able manipulate that data via one of the following.

You can save your engagements in a compressable small file size file.
You can play the game in low quality settings, yet the stream will be able to be re rendered in any setting you wish.
You can produce a video from the stream in highest video settings straight to file,
You can direct the data stream to another rendering service in your local network to produce a completely rendered view, sans chat / possible system information, which can be passed directly to twitch / 3rd party streaming site.

well if you would provide an interface where i post a kill id, and it gives me the last 300 ticks of the grid where that kill occured, that would already allow for some amazing applications.

but for that you would need to record and store all ticks per grid, which probably is way too much data.

Understandable, but could we look mid-range future at a configurable on/off switch, the same way there's advanced camera tools for filmmakers? Playback is obviously it's own nasty beast but seriously the potential of this thing is tremendous. We have a couple of really great movie-makers in our corp, if we could record a fight (in w-space, so often following similar parameters to an AT match) and they had the tools to go back and re-shoot some of it with better camera angles and less UI?

Look, just from a marketing perspective this thing has amazing potential. What would you rather watch, a bunch of colored brackets at minimum visual settings or a ship blazing through combat with all of the art team's work on full display? You wouldn't even need to make trailers anymore! We would make them for you!

Obviously it's going to be a challenge to make it widely available, I fully expect that this is something that would take a year plus to make right, but consider this one more voice calling for you to put the work into it.

This is not standard practice and I'll hope you reconsider. If you are returning json, your mime-type is application/json. If you need to version your API, as most APIs do, you should either change the resource identifier (/v1/endpoint to /v2/endpoint) or create your own header (e.g. API-Version: 0.00.1-build5290 if you must be so granular). I specifically say to use API-Header because, even though it is not a standard header, it is a header in common use for exactly this purpose. Further, RFC 6648 deprecates the use of X- headers in favor of all headers being treated like they could become acceptable standards in the future (as the API-Version header is very likely to do).

I don't want to get into an argument over this, as the system will stay this way, but I disagree with the following:



While I know that many use application/json as the "json" mimetype, I think this is wrong.

See, Json is not what I'm returning. Json is how I encode what I'm returning. The representation of the resource you are transferring is represented in a mimetype, say application/vnd.ccp.eve.TournamentTeam-v1, and the encoding of that representation is +json.

Should we decide to support xml in the future, you'd request application/vnd.ccp.eve.TournamentTeam-v1+xml

In any event, this is not going to change. If you don't like it, that's ok. But I think if you give it a try, you might find that this way is quite nice to use.

TL;DR: no special header, no url /vX/ style. Give me an Accept header and if I can match it you get exactly that, if not, you get the latest available representation

Current best practice when using an API-Version header is to make it a request header. Some people say it should be required, but I think this limits the ability to RESTfully request without manually creating the request (e.g. if I access /endpoint and have authenticated in some fashion does version really matter? I think a default is okay and should be noted by the server in some fashion) and REST is supposed to be as simple, and logical, as possible.

Other options I've seen and like, but have little practice, is adjusting the Accept header, which supports arbitrary parameter. You could then send a request like this:
Accept: application/json; version=2.0, application/json; q=0.1; version=1.0

That request would mean, "my application is compatible with 2 versions of the API, but I prefer the new one." the server would then respond with
Content-Type: application/json; version: 1

This says, "yeah, you tried to access the resource using the new version, but this particular resource doesn't support the new version yet." (See RFC 2616 about the accept header and additional parameters; here's express, a node.js framework, supporting additional information on the accept header as an example of practice: https://github.com/visionmedia/express/pull/1563)

All of these options have drawbacks, however. I don't know if the drawbacks are as bad as a non-semantic mimetype that changes with every version, especially when the mimetype is basically implementing the last example I gave in a very ugly manner. Here's the same example as above using CCP mimes using the same scenario as above:

Accept: application/vnd.eve.ccp.Tournament-v2+json, application/vnd.eve.ccp.Tournament-v1+json; q=0.1
Content-Type: application/vnd.eve.ccp.Tournament-v2+json


I'm not arguing, I'm discussing the disadvantages of your implementation vs. the other options that are becoming widely accepted as best practices.



I'd have to disagree with your definition of a mimetype, but I can understand why you made your decision based on that definition. A mimetype identifies the encoding of a resource so that an application using the resource knows how to manage it (See original definitions and uses born out of STMP). By your definition, text/html is not a reasonable mimetype as, since it is my website, I should really be saying that the resource is of type text/vnd.zael-jun+html (after all, the HTML on my page is of a completely different format than any other page, even assuming i only use standard tags). This position is not reasonable. The resources is /zael-juns-site/endpoint, the encoding is text/html but, you know what, I also give my resources in application/json for the cool kids. The only thing that matters is that you know how to parse and use the resource, which you can do because I've used standard mimetypes.

Further, as I said above in response to Nicen Jehr, this implementation is really just smashing the Accept header parameters into one mimetype instead of using the ability to set parameters within the Accept header. I can see why you might be doing it for ease of use, and I'm sure you'll get along fine if you don't change it, I was merely pointing out more acceptable and standard ways of handling such problems. While this is your application, being such a big and powerful player out there I think it is a good thing to set good examples for those that will follow in your footsteps.

Why don't you just make ten louder and make ten be the top number and make that a little louder?

Long ago, in a discussion far far away, there were magical words CREST and OAuth used in the same sentence. Any news on this, or have I been dreaming?

I'm asking because due to lack of information I've been starting to implement my own 'middleman' service (essentially, a OAuth-enabled API proxy, allowing small apps access to auth-protected data without having to manage API keys themselves) for EvE-related projects.

I started development due to lack of new CREST-related information, but if the project is still being worked on and will have such abilities (will it?) I'd be more than happy to stop and wait - a CCP-run service would be more 'legit'. And I wouldn't have to maintain it myself :)

So, is it feasible to expect such API functionality deployed against TQ data before, say, winter expansion?

PS Please use standard mime types - in my experience it's much easier for API consumers to work with additional header rather than merge that information into content-type.