progwml6 / javacurseapi Goto Github PK

Only applicable if retrofit will be selected as REST backend:

• com.squareup.retrofit2:converter-gson:2.0.2 has dependency to com.google.code.gson:gson:2.6.1
• Adapt their gson converted to work with gson 2.2.4

Project is java 8 now. Rewrite JSON (de)serialization code to be more robust and safe.

Make it faster:

• save ping reply times
• reconnect if time too old

That should make detection faster than waiting websocket implementation to detect failure.

Things to research:

• Do we need to use the soap login apis(.net binary encoding) as well or will the token data from the REST apis work
• Enums used in the mod/pack data dump file
• Hashing data from mod/pack data dump file in java

see https://github.com/progwml6/JavaCurseAPI/tree/soap-experimentation for research into this
along with https://github.com/progwml6/JavaCurseAPI/blob/soap-experimentation/src/main/java/com/feed_the_beast/javacurselib/examples/app_v1/SoapLogin.java

The associated websocket API's are deprecated.

This is a JS change set for this deprecation: njibhu/cursejs@2988e35

For the V2 version of the library, we want to make this more efficient, and event based for easier implementation, expansion, etc.

Current TODO list:

Event Handler:

• https://github.com/bennidi/mbassador

Some preliminary experimentation done in: master...jikuja:retrofit

But how to use retrofit? What is cleanest solution or most future-proof solution?

By default retrofit uses Call interface(https://square.github.io/retrofit/2.x/retrofit/retrofit2/Call.html) which can be executed asynchronously with enqueue(Callback<T> callback) or synchronously with execute(). Retrofit also provides service call adapters(https://github.com/square/retrofit/tree/master/retrofit-adapters) for supporting other return values from service calls than Call.

I wrote my experimentation with adapter converting Calls to java 8 CompletableFutures. I experimented both BodyCallAdapter(type 2 in my branch) and ResponseCallAdapter(type in in my branch) by using both synchronous and asynchronous requests. Any feedback: which one is nicer/cleaner/easier to use? (usage examples are in CurseApp.java) or should Call interface be used?

Ps. I will add similar CompletableFuture interface into Websocket.sendMessage() later. Value returned by request will be CONVERSATION_MESSAGE_RESPONSE...

The requests should be held in a queue that releases them as it can
100ms between requests has been known to work for other projects.
I'd like to get that lower if possible

If this doesn't happen some requests will continue to get blocked by the api's throttling system