Open JDGrimes opened 10 years ago
One thing that must be considered is that we currently offer the ability to specify a custom meta_key
for a points type, providing instant integration with other plugins. We'd have to decide whether to preserve this feature (at the moment, I'd say "yes").
An idea I've been toying with is abstracting out the underlying points API and making it storage agnostic. In other words, each points type could be stored in a different manner. This could be achieved by creating an abstract class (think "interface") where the methods add
, get
, set
, etc. were abstract. Other methods needed would include get_top_users()
. We'd also need each class to handle queries, too. Actually, logs queries would remain the same, but running other queries on the users points (not the logs) would need some treatment.
This would provide the benefit of making the plugin more versatile. However, it would also make it less extensible, in the sense that it would cramp extensions from directly querying/handling points, because they wouldn't know how they were stored. However, this could be partly overcome by providing an easy method of determining what features each points handler back-end thingy supported. Different back-ends could then provide support for non-core functionality at their discretion.
Another interesting aspect which could be explored if we go this route is abstracting points away from users. Sounds a little crazy, maybe, but I've had requests to make it so that a group of users can have collective points. This makes sense from a gaming perspective when you want to have teams that only earn collective points which don't affect the points of the individual. And beyond that, the possibilities are literally limitless. I don't want to bite off more that we can chew right now, but maybe we can consider laying the groundwork for something like this if we end up extracting the points type back-ends. I do fear that just that in itself could serve to over-complicate things, and this more so. But if done right, it should keep the plugin simple, while increasing extensibility exponentially.
I think we need to explore this API as a module first before doing it, similar to what we are doing with the hooks API.
Also, this isn't backward-incompatible.
This is, perhaps, a long-term project. I think we should consider moving the points values out of the user meta table. The table's performance leaves much to be desired, especially on large sites. The
meta_key
andmeta_value
columns aren't indexed, so most of our operations are probably pretty slow. I think this is something that can be achieved in a backward compatible manner, without too much effort. And I think the effort would be worth it.