On 16/06/07, Domas Mituzas midom.lists@gmail.com wrote:
We do more just than retrieving data - we end up crunching it, rerunning related queries (e.g. linkbatches), etc. The distance of UI and data access code is religious debate, but I still feel that frontend developers should understand what is needed at the backend to fulfill the task. Probably that is not that common in enterprise-y world, where abstractions are really common, but on the other hand, we're not running on enterprise-y budget.
API seems to be the work to solve many hypothetical problems, whereas mediawiki has a very specific task to handle. Now, throwing away the code and putting anything generic in between would not help with efficiency. Many of tasks we're used to do efficiently would fail quite a bit if say ActiveRecord would be used.
Generic code usually works as long as there's nobody actively using it (what applies to all API code, whenever someone starts using any function, we have either to disable or adapt bits..)
*shrug*, I feel that anyone telling about "we should have separate biz-logic level" doesn't really know biz-logic of mediawiki - but probably I'm wrong.
I think this is an excellent point, and well summarised. Let's face it - we don't have a large, salaried, professional development team, nor a large, salaried systems administration team. We have to use every trick in the book (and quite a few that aren't in the book) to keep things running efficiently, and quite often, you'll notice this in the form of Domas making apparently subtle updates to the code, for example, which make a hell of a difference.
I don't think we can afford to sacrifice a large chunk of our existing methods by completely refactoring MediaWiki to the extent that all "business logic" and "UI code" are separate, but I *do* think there are distinct areas where this could probably be done without too much hassle; query pages (or their successor), login, etc.
I don't think it's appropriate to mindlessly refactor a lot of the existing stuff for page views, editing, histories, all the common operations the main application is used for..."for the sake of it", or because some "consultant" drew a bunch of pictures and convinced us all.
The right balance needs to be found.
Rob Church