General review
liach opened this issue · 3 comments
Requesting an overall review from @i509VCB before formal submission of this draft to the fabric api.
This draft is production-ready.
Gave it a good look through. Many of the concepts are actually quite interesting. Mainly a few questions is what this whole review consists of.
Would it make sense to overload the void respond(PacketByteBuf buf);
method into something like
default void respond(PacketByteBuf buf) {
this.respond(buf, null);
}
Similarly below with the CompletableFuture
methods as well?
Maybe have a way to check if the client's own play sender is available?
This kinda seems like internals to me. Is there any reason this is exposed?
If this is needed, maybe explain what the query id corresponds to more precisely.
Maybe say @see io.github.fablabsmc.fablabs.api.networking.v1.client.ClientNetworking for networking on the client.
Or something similar if possible
Maybe move this and PacketListenerCallback to a callbacks
package to clear up a bit of the root package?
Throw a /* @Nullable */
on the method so when we got annotations in fab api we can just search and replace those comments with the annotations?
Like the case above in ClientLoginConext
, would it make sense to overload the method with no future listener to call the method with a future listener but pass null for the future.
I think there is a getClient
call or would work with just an accessor to get the MinecraftClient from the ClientLoginNetworkHandler
Similar situation like above here is possible:
https://github.com/FabLabsMC/networking-api-v1-draft/blob/master/src/main/java/io/github/fablabsmc/fablabs/impl/networking/client/ClientPlayNetworkAddon.java#L119-L122
Maybe use Identifier#tryCreate
here so you can just null check
Mark this @Unique
Repeast that with any fields you add to any mixins
Icon will obviously be changed when PRed to Fabric API
- For providing default impl for overloading, I'd argue that I will leave the implementation in the impl package than leaving default impl in the api package.
- Client's own play sender is initialized the same time as client player's network handler, so that check you suggest would be extraneous.
- The query id is like the "message id" in https://wiki.vg/Protocol#Login_Plugin_Request which can be totally internal and be left unexposed if desired
@see
tag cannot include a description- Don't think a callback package with like 2 callbacks is very necessary. The root package is just a set of interfaces defined that expand from the Client/Server networking; they aren't entry to the API themselves, but part of the API.
- Adding
/*Nullable*/
sounds good - Again overloading goes to impl
- Since we can call
MinecraftClient.getInstance()
don't think it worthes to add an extra accessor, and in a short while don't think minecraft can have two concurrent clients at once Identifier.tryParse
literally just throws that exception but eats that exception message, and I want that exception message@Unique
sure, dont' think it has a potency to clash though- Icon definitely subject to change
So a few changes:
- Add
/*Nullable*/
to packet receiver - Add
@Unique
to client connection field - Stop exposing query id for login queries, not much point
- Remember to change icon when it's part of a fabric pr
I'd say the @Unique
isn't just for clashes but also acts as a sort of decorator telling maintainers that you added that field.