Skip to content
This repository has been archived by the owner on Feb 5, 2021. It is now read-only.

General review #3

Open
liach opened this issue May 2, 2020 · 3 comments
Open

General review #3

liach opened this issue May 2, 2020 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@liach
Copy link
Collaborator

liach commented May 2, 2020

Requesting an overall review from @i509VCB before formal submission of this draft to the fabric api.

This draft is production-ready.

@liach liach added the help wanted Extra attention is needed label May 2, 2020
@i509VCB
Copy link
Contributor

i509VCB commented May 2, 2020

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.

void respond(PacketByteBuf buf);
/**
* Sends a response to the server.
*
* <p>The {@code response} may be {@code null} to indicate a "not understood"
* query response.</p>
*
* @param buf the content of the response, may be {@code null}
* @param callback a callback when the response is sent, may be {@code null}
*/
void respond(PacketByteBuf buf, GenericFutureListener<? extends Future<? super Void>> callback);

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?

public static PlayPacketSender getPlaySender() throws IllegalStateException {
ClientPlayerEntity player = MinecraftClient.getInstance().player;
if (player == null) {
throw new IllegalStateException("Cannot get packet sender when not in game!");
}
return getPlaySender(player.networkHandler);
}

Maybe have a way to check if the client's own play sender is available?

/**
* Returns the integer ID of the query response.
*/
int getQueryId();

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.

*
* @see io.github.fablabsmc.fablabs.api.networking.v1.client.ClientNetworking
*/

Maybe say @see io.github.fablabsmc.fablabs.api.networking.v1.client.ClientNetworking for networking on the client. Or something similar if possible

https://github.com/FabLabsMC/networking-api-v1-draft/blob/master/src/main/java/io/github/fablabsmc/fablabs/api/networking/v1/PacketChannelCallback.java

Maybe move this and PacketListenerCallback to a callbacks package to clear up a bit of the root package?

https://github.com/FabLabsMC/networking-api-v1-draft/blob/master/src/main/java/io/github/fablabsmc/fablabs/api/networking/v1/PacketReceiver.java#L59-L61

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?

https://github.com/FabLabsMC/networking-api-v1-draft/blob/master/src/main/java/io/github/fablabsmc/fablabs/api/networking/v1/PacketSender.java#L40-L46

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.

https://github.com/FabLabsMC/networking-api-v1-draft/blob/master/src/main/java/io/github/fablabsmc/fablabs/impl/networking/client/ClientLoginNetworkAddon.java#L121-L124

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

https://github.com/FabLabsMC/networking-api-v1-draft/blob/master/src/main/java/io/github/fablabsmc/fablabs/impl/networking/AbstractChanneledNetworkAddon.java#L148-L153

Maybe use Identifier#tryCreate here so you can just null check

https://github.com/FabLabsMC/networking-api-v1-draft/blob/master/src/main/java/io/github/fablabsmc/fablabs/mixin/networking/ClientConnectionMixin.java#L58

Mark this @Unique
Repeast that with any fields you add to any mixins

https://github.com/FabLabsMC/networking-api-v1-draft/blob/master/src/main/resources/assets/networking-api-v1-draft/icon.png

Icon will obviously be changed when PRed to Fabric API

@liach
Copy link
Collaborator Author

liach commented May 2, 2020

  1. 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.
  2. Client's own play sender is initialized the same time as client player's network handler, so that check you suggest would be extraneous.
  3. 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
  4. @see tag cannot include a description
  5. 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.
  6. Adding /*Nullable*/ sounds good
  7. Again overloading goes to impl
  8. 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
  9. Identifier.tryParse literally just throws that exception but eats that exception message, and I want that exception message
  10. @Unique sure, dont' think it has a potency to clash though
  11. 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

@i509VCB
Copy link
Contributor

i509VCB commented May 2, 2020

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.

@liach liach assigned liach and unassigned i509VCB May 2, 2020
@liach liach added enhancement New feature or request and removed help wanted Extra attention is needed labels May 2, 2020
liach added a commit that referenced this issue May 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants