BanService implementation discussion

[8:55 PM] A248: I'm developing a punishment plugin, and for correctness' sake I'm implementing BanService. This plugin is already functional on other platforms; I'm moving it to Sponge. However, I've encountered a conundrum.

On incoming users, Sponge checks the BanService for bans applying to that user's UUID or IP address using the find methods. Yet, the plugin I've developed has a more complex determination of whether a user has a ban. If I implement the find methods in accordance with the contract, then the plugin I've developed loses major functionality. If I implement the find methods in a special fashion, the violation of contract would cause awkward behavior in other plugins, which I do not wish for.

So, this leads me to question whether I should implement BanService at all, if my punishment plugin does not fit the Sponge API's determination of what constitutes a "ban service." Do you have any suggestions?
[8:57 PM] Zidane: Well you should explain why implementing find is a problem first?
[9:00 PM] A248: find requests a ban on a certain UUID or IP address. The plugin I've developed can have a ban on 1 IP address that nevertheless has the effect of banning a user on a different IP address. This might happen, for example, if the second user on a different IP address used to have the banned IP address, but no longer does.
[9:02 PM] A248: This isn't the only problem. To determine whether a user is banned, I require their UUID and IP address, not one or the other. The find methods provide only one of these details.
[9:05 PM] Zidane: Well I think the fundamental issue is the API's BanService is designed around how Minecraft does bans which is profile or ip. Not both.
[9:05 PM] Zidane: It doesn't make it wrong it is just how it is
[9:06 PM] Zidane: I'd be curious how you implemented it on other platforms unless you went straight to the internals
[9:06 PM] Zidane: (Or if they just say the hell with it and ignore Vanilla's ban management)
[9:06 PM] A248: On other platforms I simply listen to the relevant connection event. They don't have a service like Sponge does.
[9:07 PM] Zidane: Which is fair, your concern is worrying about how other API calls will happen with the BanService
[9:07 PM] Zidane: Cause, truthfully, you don't have to implement the service. You could certainly just handle the connection event anyways...but yeah would make the BanService always report wrong lol
[9:09 PM] A248: Okay then. That's unfortunate, but I suppose there isn't much to be done about it. Thanks for the advice
[9:10 PM] Zidane: I am always open to changes but I am unsure I could justify this one simply because...well for starters it would be complicated to answer how to implement a find with both profile and IP with just Vanilla's system heh
[9:10 PM] Zidane: What do you check? The profile? The ip? lol
[9:10 PM] A248: Right, I was looking at the Sponge implementation and didn't find a way around this, not without some refactoring
[9:10 PM] A248: (By "refactoring" I mean refactoring vanilla's own handling)
[9:13 PM] A248: By the way, would you suggest I listen to the ServerSideConnectionEvent.Handshake in that case? Ideally I would rely on an asynchronous event, but an event which happens after authentication, and the handshake is therefore the only candidate.
[9:13 PM] Zidane: I can see a way that this would work
[9:13 PM] Zidane: but I agree
[9:13 PM] Zidane: the Sponge impl has to be re-worked
[9:13 PM] Zidane: lol
[9:13 PM] Zidane: and it is an API break so it'd have to go to API-10