Re: Activity DB Design Discussion
I don’t think it will necessarily replace the other components, but what it will do is handle all of the generic functionality that is now handled by the components themselves. Since each component might handle it a little bit differently, it is difficult to get them all to play nice with each other.
What is being proposed is that all of the complexities of the inner guts of buddypress start to move more towards the heart of the app, so new components and plugins don’t have to worry about implementing so many redundant functions. Recording activity and updating meta data are two obvious ones, but avatar handling is another. Even though there are core functions to handle most of this, you still have to create a bunch of wrapper functions in order to support filters and actions, etc. Just some basic polymorphism would elimiate thousands of lines of code. Imagine instead of copying pasting 30 functions, you just extend the class and define your slug in the slug() method, and then whenever you call a parent class method, all of them automagically store your data the right way for you.
In the future if a new component comes along that has some cool functionality that all other components can benefit from, then this could be refactored “up” into the activity component, or whatever it ends up being called, so the new functionality could become instantly available to everything else.
