Skip to content
This repository has been archived by the owner on Aug 26, 2023. It is now read-only.

Data handling (central storage) #7

Open
asofold opened this issue Sep 18, 2013 · 4 comments
Open

Data handling (central storage) #7

asofold opened this issue Sep 18, 2013 · 4 comments

Comments

@asofold
Copy link
Member

asofold commented Sep 18, 2013

A central object for a player could store data, as well as configurations (if set per player), all by check types. The problem would be how to fetch those efficiently and as type-safe as possible.

A getData(CheckType) method would likely have to return an Object. In the context of overriding checks of the same type it might not be fun to have to check what object is returned (not sure we allow such anyway, but it might be needed for backwards compatibility in some cases).

Making the method return "the desired" type will probably demand passing a class or similar in order to be able to check and return null or invoke a registered factory-method or return an actually present object.

We could consider having getData(CheckType) as the "slow method" for such as command use rather, while we maintain a getData(Class) or similar for "fast" access, which then returns the desired kind of thing, depending on registration. Of course this does not do recursive checking, it is meant for direct lookup.

After all it is still open how to do the contract for data / configs within a central player data object: Unique classes for differing check types? Allow storing multiple classes per check type? Register arbitrary object factories and classes for a check type and receive an integer id and/or a fast-access object to use for getting data fast later, something like "DataHolder getFastAccess(CheckType checkType, Class dataType)"?

The DataHolder would be for storing it during runtime, raising the problem of what happens on data removal or adding a new component or removing one such that the factories have to change (could provide events + setting the factories to null-factories on unregistration, it would probably be advanced user anyway.).

Should make example implementations / interfaces, probably...

@MyPictures
Copy link
Member

I wonder if we can do something against duplicated names (NPCs that carry the same name as other player) also. Will Consistency checks also be implemented in NoCheat? They seem to do a pretty good job in NoCheatPlus.

@SuperSpyTX
Copy link
Member

As somebody who can't really translate, I'd definitely love to see some examples.

I learn better, visually.

@asofold
Copy link
Member Author

asofold commented Sep 19, 2013

Maybe use this for firther confusion: https://gist.github.com/asofold/6622498

@asofold
Copy link
Member Author

asofold commented Sep 21, 2013

This might be the next session :p - main question will be if to have unique data classes, or combinations of checktype + data or some general type object + data. An alternative can be to register data classes with a range of (check) type objects, so we can have different mechanisms to accessing all check-related data.

Another point to decide is if / how to use a base class for check data, in order to call things like onClearData(CheckType xy) or onPeriodicCleanup(CheckType yx), or if we allow setting certain policies for data types (DataBroker.setDataRemovalPolicy(Class<?> dataType, DataRemovalPolicy policy) and similar.

Then again we will have to consider having two-fold access (async + sync) ... store global data (in data broker, not in player data), if to have per-world data or just general data, and other side topics.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants