The current state of ESI

[ccee2abf-fb28-497b-88ca-ae3643da4a8f]

See title.

Proposed changes such as the new bookmark endpoint and even smaller changes such as new notifications in the notification endpoint appear to be either heavily delayed or just not happening at all.

If ESI is just being maintained to keep it going, and no new features are considered. Please consider sharing that information with developers so that they can manage expectations.

[HakShak]

Here's the "short" version:

A lot of work has gone into moving ESI endpoints internally from JSON to Protobuf. It's a long journey:

This is slow because we are using ESI to properly model large portions of Eve Online through Protobuf. This means undoing/untangling/redefining designs which have not aged well and in some cases are incompatible with the patterns required for systems like ESI.

Furthermore, we have had to pause this progress as we support teams who are learning and using the technology born out of ESI. The latest of which being the Proving Grounds Leaderboards.

On top of that a lot of support goes to the teams modelling more and more of the Eve Universe in Protobuf as newer features are added to internal tooling and Portal.

Our current tasks have us focused on two highly coupled tasks: gRPC in the Eve Client and taking local chat out back to be shot. Repeatedly. Until it connects.

Once we emerge from that work we can reevaluate where we are.

[ddouglas]

I just want be the first to say Thank You for not ignoring this and providing the update. We will most likely be using this issue as the response to questions of this genre for the foreseeable future.

[colcrunch]

@HakShak any chance of another state of ESI update a year later?

[HakShak]

So that's out of the way we can hopefully speak more to ESI, but right now we would still need to prioritize the migration from above. Quasar might also change the way we expose things in the future.

[ghost]

So that's out of the way we can hopefully speak more to ESI, but right now we would still need to prioritize the migration from above. Quasar might also change the way we expose things in the future.

Hopefully GraphQL for a public interface as requested here #1309

Also if there is a problem with commitment of resources and time from CCP on a public API perhaps they should consider charging a fee to access/use it? Whilst I understand that suggestion would be unpopular, it would certinally be an incentive for CCP to improve things on the API (the precendent here is they require a valid payment in order to obtain a devkey, and some applications, will force users to use their own devkey anyway, notably desktop apps due to their nature of being published and out of the developers control in the hands of a user rather than a centralised webservice, so it is not a new notion from CCP to charge for the API).

[evanova]

So that's out of the way we can hopefully speak more to ESI, but right now we would still need to prioritize the migration from above. Quasar might also change the way we expose things in the future.

Hopefully GraphQL for a public interface as requested here #1309

Also if there is a problem with commitment of resources and time from CCP on a public API perhaps they should consider charging a fee to access/use it?

Given that we do not make any actual money for our work, charging a fee for ESI is the worse idea I've read in a long time and most likely the best way to halt third-party's dedication. it makes no sense whatsoever, and is the exact opposite of the current partner's program idea which is for us not having to spend money to maintain our apps.

Now reading this thread, what I still wonder about is why a public API like ESI is tied to the Eve client or anything else other than just being a facility for third-parties. Isn't that a source of a lot of development pain? I imagine having to think about not breaking Eve or other apps while changing some public REST endpoints makes the whole process rather heavy and difficult.
Maybe what could happen is decoupling Eve's internal from the public part of ESI. This would allow everyone a lot more flexibility in making changes on both sides.

[ghost]

charging a fee for ESI is the worse idea I've read in a long time and most likely the best way to halt third-party's dedication

We already have to have a valid payment registered to get a devkey, whilst that makes sense for online web services and websites centralised services, it makes absolutely ZERO sense and a RISK for desktop published applications that are outside the control of the developer. Many developers are now opting to ship with the user bringing (registering their own payment method with CCP to obtain it) their own devkey to use it. Even Evemon now has a field to use your own devkey. All my apps for the desktop will force users to use their own devkey. They won't be using MY devkey that I paid for (registered a payment method for on CCP's site).

I will NEVER allow MY devkey to be used on desktop published apps. EVER. Use your own devkey (and thus pay for it), or build your own.

By allowing a published desktop app to use MY devkey, that means I am liable for the user's actions and the risk is them abusing the app, by piggy backing on the devkey, by modifying the app in memory/binary and so forth. No thanks to the devkey.

Web site services and desktop apps are not the same, yet we have to publish desktop apps using the same devkey concept. Desktop apps published have ZERO control (and thus liability) for the user's actions / modifications.

What the devkey is doing is KILLing desktop apps, in favour of centralised web site service based apps. That way they can ADVERTISE their partnerships and product that cannot be done with a desktop app as easily. That's what CCP wants.

[fuzzysteve]

Just to be clear, having been around and involved with the discussions wrt the payment thing:

The valid payment thing is only so CCP can identify who you are in the real world. It's not so CCP make sure you paid them money. It's why Paypal didn't count for it. Only credit cards.

Payment for API access or development access is a terrible idea, which has been talked about in the past, and thrown out as a concept. It will stifle development. I know I, for one, would not pay for it. I would walk instead.

Also, please don't try to speak for CCP. You don't work for them. You don't have a pipeline to them behind the scenes.