Event registration

[SuperSpyTX]

asofold: we need a technically functioning (and efficiently functioning) framework for event-registration

[asofold]

Similar to the NCP feature "managelisteners" this thing will ensure that we only register one Listener per event-type, allowing checks and other to register with this service. Basically this allows to register with some sort of ordering ("before all ncp" checks, "before moving checks but after data managing" and similar), for the sake of compatibility and also on-the-fly check addition and removal, keeping impact on the system minimal.

One problem for modeling still is the "multiple priorities" question and if / how to abstract from event-priorities.

The Data-Source model could just allow to provide this service for Bukkit + extra ordering, but it might be feasible to have our own abstraction to event priorites (still leaving open cross-plugin stuff which then would need knowledge about the underlying server mod/API).

[SuperSpyTX]

Event Priorities should be handled based on which dependencies are needed, the more dependent, the likely it'll be loaded last, the less dependencies, the better.

Obviously we're talking the # of unloaded dependencies, so we won't load the unloaded dependencies until all the others have loaded, then we load the unloaded, then load all the other checks.

That might sound bad, but do we really want to block loading for dependencies? We could but whatever.

[asofold]

If we want to allow checks that are independent of the server mod / API then we need our own priorities.

We will have them in some way anyway even if only building on Bukkit (e.g. regex-based register-before and/or register-after ordering) - but the question remains what we do with non-bukkit systems.

In fact i have been imprecise here on the Bukkit-question - it would not make sense to listen to a BukkitEvent but without Bukkit priorities - of course i have in mind the doubled ordering question with Bukkit-listeners + their registry and the abstracted data source providers (i.e. abstracted events) and their registry (if they have another one).

Thinkable is "not to do it", i.e. use Bukkit Priorities, also possible to think up some priority scheme that we use internally and that gets translated into bukkit, or we do something hybrid-like with specifying priority-preferences with strings, matched against Bukkit event priorities, thus allowing for abstracted checks that still can ensure to come after mcmmo (Bukkit priority) but before other NCP components (internal ordering, provided that is possible at all with either plugins Bukkit-priorities).

So we might end up with something like primary priority preference (mod dependent) and secondary (regex or something), while the secondary rules if the primary is not given, so the secondary suffices if you just want to relate to core NCP or check functionality since all registered checks have some generic identifier added that one can match against. Question is if this solves the general problem of layers of listeners and ordering.

[asofold]

Do mind that my idea might boil down to the minimally needed "first-step-in" model.

I also forgot to mention that the ordering idea is also extendable to other registries within NCP that don't use the event mechanisms of Bukkit (e.g. hooks, reload listeners, consistency checkers, add-in components, logging stuff), so it might be something to rely on as the main thing unless cross-plugin compatibility is needed.

So this turns to the question if the abstracted data sources should provide some priorities as well or have some sort of mechanism to mirror the underlying event priorities - will each source (abstracted event) have an extra registry to be registered with the core registry and how do all those unfold?
(And do note that abstracted events can make sense even for moving checks, to contain all the digested data and caching already.)

[asofold]

I think i should make this more clear, since i needed too many letters to remember what i meant in the first place :p.

1. We do need to manage listeners and provide a way to register before/after certain other components in order to receive events earlier or later than them, because for on-the-fly check registration just demands this due to dependencies. This also is desirable for providing compatibility plugins that can wrap NCP listeners in a reliable way with this.
2. This would be all fine with a generic Bukkit-Listener registry like NCP has with the ListenerManager that then handles the order (interesting could be to allow a registration with priority to before-x and similar without stating Bukkit priorities, but that is an extra feature).
3. Difficulties might arise if we put our abstracted data source providers upon the Bukkit-based (and/or other) ListenerManager instances - now the Bukkit-priorities might not be desirable as main concept for registering checks that use the asbtracted data sources, but the bukkit-priorities might still be needed to provide cross-plugin compatibility or to be sure one is "really early" with the listener and not just before X. For this purpose one might want to provide something that allows referencing priority schemes of Bukkit or other mods and/or provide something that abstracts from bukkit / others priorities but somehow translates into those. These could also exist in parallel, e.g. the possibility for just a general "register to receive first but modifyable" could co-exist with "register before all of Moving checks" and "register before Bukkit@Eventpriority.LOW" or similar concepts, so these things will translate into some order down the chain of data source providers. This might still raise the problems which ordering is meant for which level and how to ensure such, but i hope i made the main points more clear now for a start. We could probable use drawings for this :p.

(I think the order must be fully customizable for a component, but having some "order by dependencies" option might be fancy as well, but is an extra convenience feature like check-in-one-class registration.)

[asofold]

As long as we don't implement abstracted data sources (like already digested moving data), we can do with a Bukkit based ListenerRegistry that allows for some ordering between listeners and ensures every Bukkit-event is only registered once.

This manager would be obtainable via the generic registry at first so it won't pollute the API in any way, other than that one has to know that it exists on servers that implement the Bukkit API. [For Bukkit one could also add an extra access-class to get Bukkit-specific defualt registries / components.]

Could be feasible to melt all the above text into a generic listener registry later, that does not make use of any external API priorities etc. directly, but translates into what is available for the "desired context". This could detect Bukkit Listeners (only available on Bukkit Systems) and otherwise delegate on base on some context arguments. Still this might well be omitted, because the generic registry allows you getting the components you want to register with, at the cost of the registration process being a little bit less convenient.

We do have to keep an eye on some RegistrationContext thing later, for the case of external plugins adding stuff, in order to be able to remove added components with other plugins disabling, if set so.

[SuperSpyTX]

As for priorities. We also need to know how we should be handling setbacks. Should we be handling setbacks via our own API or through Bukkit API?

[asofold]

For set-backs we should refer to the set-back handling issue/threads.

Of course cancelling mechanics need to be thought through somehow.

[asofold]

We must make this component work like 100% in order to succeed. In the past there have been uncertainties with the events really getting processed correctly, i did not have time to check on it, though there have been servers using the managelistener setting set to true without problems, seemingly. We do need to test this out, might be that generics were set up wrong (extends/super/isassignableform, need to re-check what was used!?).

The other question is if/how we can get rid of a little bit of reflection - also in the Bukkit API implementations event listeners each use reflection which is somewhat inefficient. Using interfaces would however not necessarily work nicely with typical schemes, like having to implement one small listener for each event.

[MyPictures]

managelisteners was a experimental and funny feature in NoCheatPlus (kinda still is). We just got some strange problems such as our BedLeave check not checking any-more. Need to research on this one more for sure...

[asofold]

If you can find any event not getting processed, would be cool to know - though we might as well test that in another way with a new implementation of it (test plugin).