Hi everyone,
Everything I said below still stands, except now there are only two days, so please make the most of them.
Don't make me break out the caps lock. I'll do it. :-)
Thanks Rob ---------- Forwarded message ---------- From: Rob Lanphier robla@wikimedia.org Date: Wed, Dec 11, 2013 at 12:41 PM Subject: RFC deadline approaching for Arch Summit: December 20 To: Wikimedia developers wikitech-l@lists.wikimedia.org
Hi everyone,
We're just over a week away from the Friday, December 20 deadline for RFCs as items to consider at the Architecture Summit.[1] That's not a hard and fast rule (we've never done this before), but we should definitely have a reasonable amount of time between the point an RFC is proposed and being discussed at the Architecture Summit. Ideally, we'll have taken care of everything that's reasonable to take care of via mailing list/IRC/other online meeting, and really be down the things that require face-to-face time to accomplish.
It's my hope that we're not just nibbling at the edges, but that we're actually going to talk about things that will substantially modernize our architecture and reduce our technical debt. I believe there are RFCs in the list and in the works that do that, but I also know there are areas we've discussed informally in the past that we've never set to writing. Many of the RFCs cover important areas of incremental improvement, but not all of the changes we need to make have such small increments.
Anyway, RFC submission page is here: https://www.mediawiki.org/wiki/Requests_for_comment
Rob [1] https://www.mediawiki.org/wiki/Architecture_Summit_2014
On Dec 18, 2013, at 3:30 PM, Rob Lanphier robla@wikimedia.org wrote:
Hi everyone,
Everything I said below still stands, except now there are only two days, so please make the most of them.
I have been working on some draft proposals here: https://www.mediawiki.org/wiki/User:Owyn
I think that a few of them are ready for feedback so I have moved them onto the list. Some of these ideas are things that Wikia has already implemented to some degree or another, and some of them are just things that we’d like to see some discussion about.
https://www.mediawiki.org/wiki/Requests_for_comment/MVC_Framework
- We have our own mvc framework that we’ve used to build pretty much everything in the last 2 years. The developers don’t complain about it, so it must be relatively decent. :) The original design came from Inez (who is working on VisualEditor now) and myself, and it’s been hacked up a bit from where we originally started but we think the core of it is an improvement over QuickTemplates and XML.
https://www.mediawiki.org/wiki/Requests_for_comment/UserMailer_Refactor
- We usually stick to the normal extension/hook mechanisms for our own stuff, but in the case of the UserMailer it was impossible, so we had to modify it heavily. A lot of the things that we added are basic features like priority and categories (used by our mail sending backend) and the ability to send HTML mail. The User Mailer is an example of a core class which is not designed to be extended, and it probably should be refactored.
https://www.mediawiki.org/wiki/Requests_for_comment/OutputPage_Refactor
- The output page class is another monolithic class which is a mixture of output pipelining/sequencing functions and helper functions. It creates a lot of data which is used by the skin, but also emits raw HTML and headers in a way that makes it hard to override functionality. A lot of this could probably be split up to separate the data from the rendering of the HTML page.
https://www.mediawiki.org/wiki/Requests_for_comment/SQL_Framework
- This one is more for fun but it does address something we feel is a pretty big deficiency in the core API's. We wrote a fluent style SQL library and we’ve started using it to build SQL queries in our more complicated data/reporting extensions. We like it a lot better than the core mediawiki database interface which uses positional arrays of key/value pairs. The current database api makes it almost impossible to visualize what the actual SQL is going to be, so you have to just run the code and capture the debug output. With this library, you can build up a query as an object. It has some nice side effects like the ability to cache results without extra boilerplate, and efficiently transform the query output without having to make extra passes through the result set.
The remaining proposals on my user page might be interesting for someone to look at, but they are either too vague or overlap with existing proposals for really serious consideration and I plan on merging them with the appropriate RFC’s soon.
Definitely appreciate any comments/questions!
Owen (@Wikia)
I added a sub-stub "Performance standards for new features", just a copy/summary of an old thread with some recent links. https://www.mediawiki.org/wiki/Requests_for_comment/Performance_standards_for_new_features Part of the reason for this RfC is that our performance experts are overloaded, so this needs *you* to get to stub/draft level. :) Hopefully gradual editing can work.
Nemo
wikitech-l@lists.wikimedia.org