OAuth plans
Hi Daniel,
You mentioned that "Every edit, log, etc... needs a field and code that associates an app." I am not sure if that is the way to go. That is a super major overhaul of the MediaWiki platform, has performance and storage implications. I think we should search for a solution using a mix of the following components:
1) Having a log table that contains user_id, app_id and timestamp so we can revert actions done by a particular user and app combination for a certain date range.
2) Having a policy where we clearly state under what circumstances we are free to to undo certain actions and ban a third party app.
3) The approval process by which we review third-party apps.
Drdee 03:58, 18 November 2011 (UTC)
We've been overhauling portions of MediaWiki for awhile, I see no reason to cut corners, not overhaul something that seams like it calls for it, and come out with a half-baked feature for something like this.
The only performance implications new columns have is in schema updates. New tables can also add other performance implications such as JOINS. So we're not going to get away with cutting corners and pretending that we shouldn't overhaul something and instead implement something that doesn't need to take the best decision for performance into account. Whether that's a column change or another table with say a pair of columns that point to a table and a primary key.
And something that doesn't properly associate the app/user to a change in an absolute way, especially something at the granularity of just a timestamp feels very fragile and liable to not work right.
What we're talking about here is code that will allow for a user session that only has partial permissions of a normal user session. Something that MediaWiki naturally was not coded to expect. Naturally it's possible that a feature like this will require a partial overhaul to make work correctly.
Also I don't like the idea of the core functionality of associating a change with an app being implemented in an extension. That seams like something that's liable to not be very compatible with extending into extensions. Some extensions add new api portions, and I'd hate to see an implementation of a feature that includes OAuth and the 3rd parties using it can't use something like LQT's api because LQT can't integrate the code needed to support OAuth in it's api. Or see that such a feature requires a bunch of tests all over extension code to ensure that the extension can actually work when the OAuth extension is not installed.
