Architecture meetings/RFC review 2013-11-20

Wednesday, November 20, 2013 at 10:00 PM UTC at #wikimedia-meetbot ^connect

Requests for Comment to review

• Requests for comment/Page deletion
• Requests for comment/Configuration database 2
• Requests for comment/Text extraction

Summary and logs

The content below is an export of the original MeetBot notes using Pandoc.

Meeting summary

1. 1. Details of this RFC review meeting are available at https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-11-20 (qgil, 22:03:40)
   
   
2. Page deletion (qgil, 22:05:30)
   1. https://www.mediawiki.org/wiki/Requests_for_comment/Page_deletion (qgil, 22:05:43)
   2. : https://bugzilla.wikimedia.org/show_bug.cgi?id=55398 proposed new field; AaronSchulz suggests we go with new table (Leucosticte, 22:06:55)
   3. <TimStarling> maybe it should present a single option (a table), and maybe give a few more details about how that will work. Then we'll accept it (qgil, 22:22:57)
   4. ACTION: Leucosticte to expand on "new table" design, optionally start on prototype (TimStarling, 22:23:31)
   
   
3. Configuration database 2 (qgil, 22:26:44)
   1. https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database_2 (qgil, 22:26:53)
   2. <TimStarling> neither JSON nor CDB are really appropriate backends for a web interface (qgil, 22:34:11)
   3. https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/Configuration_database/Storing_setting_on_wiki_pages (^d, 22:38:32)
   4. https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/Configuration_database/Storing_setting_on_wiki_pages (qgil, 22:38:51)
   5. <TimStarling> I think we need to talk about requirements (qgil, 22:49:18)
   6. ACTION: legoktm and other interested devs to develop requirements list on wiki (TimStarling, 22:49:20)
   
   
4. Text extraction (qgil, 22:49:48)
   1. https://www.mediawiki.org/wiki/Requests_for_comment/Text_extraction (qgil, 22:50:00)
   2. <MaxSem> this RFC is asking for decisions on 2 things: core vs. extension and whether to store the extracts in page_props, unconditionally (qgil, 22:50:23)
   3. extracts are definitely too big for the core DB, need some other storage backend (TimStarling, 22:57:52)
   4. ACTION: MaxSem and other interested devs to discuss storage backend options on RFC (TimStarling, 23:00:17)
   5. ACTION: ^d to comment on RFC sharing experience with similar problem in ElasticSearch (TimStarling, 23:00:52)

Meeting ended at 23:04:06 UTC (full logs).

Action items

1. Leucosticte to expand on "new table" design, optionally start on prototype
2. legoktm and other interested devs to develop requirements list on wiki
3. MaxSem and other interested devs to discuss storage backend options on RFC
4. ^d to comment on RFC sharing experience with similar problem in ElasticSearch

Action items, by person

1. ^d
   1. ^d to comment on RFC sharing experience with similar problem in ElasticSearch
2. legoktm
   1. legoktm and other interested devs to develop requirements list on wiki
3. Leucosticte
   1. Leucosticte to expand on "new table" design, optionally start on prototype
4. MaxSem
   1. MaxSem and other interested devs to discuss storage backend options on RFC

People present (lines said)

1. TimStarling (71)
2. ^d (35)
3. AaronSchulz (34)
4. MaxSem (27)
5. legoktm (22)
6. qgil (20)
7. aude (14)
8. Leucosticte (14)
9. ori-l (10)
10. vvv (5)
11. bd808 (5)
12. Krenair (4)
13. robla (3)
14. meetbot-wm` (2)
15. drdee (1)

Full log

Meeting logs

22:03:23 <qgil> #startmeeting 22:03:23 <meetbot-wm`> Meeting started Wed Nov 20 22:03:23 2013 UTC. The chair is qgil. Information about MeetBot at https://bugzilla.wikimedia.org/46377. 22:03:23 <meetbot-wm`> Useful Commands: #action #agreed #help #info #idea #link #topic. 22:03:31 <TimStarling> who added page deletion to the list at https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-11-20 ? 22:03:40 <qgil> #info Details of this RFC review meeting are available at https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-11-20 22:03:41 <Leucosticte> I did 22:03:59 <qgil> TimStarling, which should be the first topic? 22:04:17 <TimStarling> we also have Configuration database 2, and we have legoktm online for that one 22:04:26 <legoktm> :D 22:04:31 <TimStarling> and text extraction, and we have maxSem online for that? 22:04:36 <MaxSem> yup 22:05:18 <TimStarling> ok, let's start with page deletion 22:05:30 <qgil> #topic Page deletion 22:05:35 <TimStarling> Leucosticte: you have made some edits to this RFC recently? 22:05:43 <qgil> #link https://www.mediawiki.org/wiki/Requests_for_comment/Page_deletion 22:05:50 <Leucosticte> yes, the two options being considered were new field and new table 22:06:23 <qgil> Everybody: please rememberto add "#info"at the beginning of sentences you want to be written in the meeting minutes. Thank you! 22:06:55 <Leucosticte> #info: https://bugzilla.wikimedia.org/show_bug.cgi?id=55398 proposed new field; AaronSchulz suggests we go with new table 22:07:25 <^d> I like this rfc and all I've read is the intro. 22:07:43 <Leucosticte> oh, I guess only use #info on major items, right? 22:07:46 <TimStarling> so you have just fleshed out these two options a bit? 22:08:01 <Leucosticte> pretty much. Platonides was the one who originally put the two options forward 22:08:13 * AaronSchulz actually coded the table option ages ago in branch 22:08:24 <qgil> Leucosticte, you're doing fine  :) 22:08:29 <^d> Question: has any thought been given to oversight migration? 22:08:30 <AaronSchulz> not that any of that would be usable now ;) 22:08:38 <MaxSem> It took us quite a time to get rev_deleted right, and page_delted will be much, much harder due to widespread use 22:08:47 <^d> We've still not migrated oversight data to rev_del, and whatever new idea should allow oversight to be migrated too. 22:08:56 <Krenair> I have a patch in Gerrit for that. 22:08:57 <legoktm> ^d: I think Krenair was working on a script to convert oversight data to revdel 22:09:17 <Krenair> It got too complex and I haven't bothered working on it for months. 22:09:19 <TimStarling> Leucosticte: are you offering to write the code for this, or are you just interested in the design? 22:09:59 <TimStarling> AaronSchulz: a branch in git or subversion? 22:10:06 <AaronSchulz> svn 22:10:10 <Leucosticte> TimStarling: offering to write code, but it looks like Aaron already started on the code, if we're going with the table option. 22:10:16 <AaronSchulz> this was the old days when brion had to review everything 22:10:29 <TimStarling> that's going back a way :) 22:10:47 <AaronSchulz> like I said, it would be from scratch to do that now 22:10:52 <TimStarling> Leucosticte may just want to look at your diff for ideas 22:11:44 * aude waves 22:12:15 * Krenair waves back 22:12:29 <drdee> is this an RFC that should be discussed at the Architecture Meeting in January? 22:12:39 <TimStarling> so everyone's preferred option is adding an archived_page table? 22:12:48 <^d> I'm on the fence. 22:13:15 <MaxSem> yep 22:13:21 <TimStarling> if revisions are left in the revision table, that makes deletion and undeletion fairly efficient 22:13:39 <MaxSem> which is a separate whee 22:13:42 <TimStarling> but I guess that is a property of both proposals 22:14:08 <Leucosticte> TimStarling, I preferred field since it would be nice to keep page IDs the same across deletions and recreations, and because deletion just is really just hiding pages from certain viewers, so the page may as well stay in the table -- that's my thinking, but the new table would be more secure by default; Aaron's right about that 22:14:09 <AaronSchulz> right 22:14:25 <AaronSchulz> you can still preserve page IDs either way 22:14:45 <TimStarling> same way we preserve revision IDs currently 22:14:49 <MaxSem> also, adding page_deleted to many queries would require a lot of index tuning and potentially more indexes 22:15:26 <TimStarling> how would Special:Contributions work? 22:16:06 <TimStarling> I guess there is a join on page already 22:16:26 <Leucosticte> oh, well if the page IDs stay the same then new field doesn't have a lot of advantages listed, other than "All page_ids live in one table." Were there other advantages? 22:16:30 <TimStarling> would we be looking at merging the code of Special:Contributions and Special:DeletedContributions? 22:17:06 <AaronSchulz> they could share more code at least 22:17:17 * ^d wonders what the schema would look like if a 1.5-style complete refactor happened...throw out all assumptions and do things the Right Way. 22:17:39 <vvv> And how many extensions will break as a result?.. 22:18:10 <MaxSem> ^d, and a migration couple orders of magnitude harder... 22:18:11 <MaxSem> :P 22:18:42 <^d> Hey I was just wondering, not advocating :p 22:18:49 <TimStarling> would there be multiple archived_page rows per title? 22:18:58 <TimStarling> oh, sorry 22:19:01 <TimStarling> that is in the RFC document 22:19:29 <TimStarling> ^d: it would probably be a field 22:20:16 <TimStarling> but a table has some advantages for b/c 22:20:34 <TimStarling> anyway, should we accept this or ask for more detail? 22:21:28 <TimStarling> maybe it should present a single option (a table), and maybe give a few more details about how that will work 22:21:34 <TimStarling> then we'll accept it 22:21:36 <TimStarling> sound good? 22:21:42 <^d> Yeah I can agree to that. 22:22:01 <^d> I'm not unconvinced on the new table, I think with some more arguments you'll have me sold. 22:22:57 <qgil> #info <TimStarling> maybe it should present a single option (a table), and maybe give a few more details about how that will work. Then we'll accept it 22:23:31 <TimStarling> #action Leucosticte to expand on "new table" design, optionally start on prototype 22:23:55 <Leucosticte> so you need info on how Special:Contributions will work, or did you figure that out? 22:24:05 * AaronSchulz can only find the patch on https://bugzilla.wikimedia.org/show_bug.cgi?id=11402 22:25:18 <qgil> TimStarling, let us know when you wnt to move to a next topic, and which one it will be 22:25:36 <TimStarling> Leucosticte: maybe just give some indicative SQL showing the kind of query Special:Contributions and Special:DeletedContributions would do 22:26:09 * AaronSchulz doubts the former would need much change 22:26:32 <TimStarling> qgil: on to Configuration database 2 22:26:44 <qgil> #topic Configuration database 2 22:26:53 <qgil> #link https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database_2 22:26:58 <Leucosticte> TimStarling: okay. so, ^d, did you have any more detail regarding what you were wondering aloud, or is that pretty much only an option we're going with if new table ends up being rejected after more details are given -- okay I guess we'll discuss later/elsewhere 22:27:36 <TimStarling> Leucosticte: obviously a change to deletion is needed, we're not going to reject the whole concept 22:28:09 <TimStarling> it's just a matter of getting the right level of detail before coding starts, so that you don't end up wasting too much time on back-and-forth in code review 22:28:39 <Leucosticte> ah, okay 22:28:44 <AaronSchulz> Leucosticte: you want to show the Special:Undelete SQL smaple in the rfc too 22:29:15 <Leucosticte> okay. 22:29:18 <AaronSchulz> and don't make it a separate page like I did in that patch ;) 22:29:19 <^d> Also, I'm curious what happens when a page is deleted & recreated. Not once, many times (it happens) 22:29:22 <AaronSchulz> ok, config now 22:30:10 <AaronSchulz> the rfc could say more about storage 22:30:23 <TimStarling> legoktm: you know that performant is not a word, right? 22:30:31 <TimStarling> just saying 22:30:34 <AaronSchulz> at some point, you need config files on each apache 22:30:34 <Leucosticte> it's in wiktionary 22:30:40 <legoktm> TimStarling: oops. 22:30:46 <TimStarling> yeah, lots of stupid things are in wiktionary 22:30:47 * AaronSchulz isn't sure where DataStore would really fit it 22:31:03 <Leucosticte> i thought the same thing when I saw it 22:31:10 <AaronSchulz> legoktm: it's used all over the web 22:31:21 <AaronSchulz> and in person...that is generally how things become new words 22:31:44 <legoktm> AaronSchulz: Really there just needs to be some kind of key-value storage. JSON was an easy choice since its human readable, and easy to use. CDB was also included if JSON isn't fast enough 22:32:16 <TimStarling> neither JSON nor CDB are really appropriate backends for a web interface 22:32:21 <AaronSchulz> right, but when people say key/value storage it's easy to get hung up on things like Cassandra, Mongo ect that are neither here nor there 22:32:38 <MaxSem> DataStore! 22:32:40 <AaronSchulz> could could be a blob in swift really...we don't even need key value 22:32:53 <^d> DataStore requires you having a connection to the database. 22:32:54 <AaronSchulz> well, one key, that would be for all the config 22:33:07 <legoktm> TimStarling: What would you suggest instead? 22:33:11 <vvv> It is not clear to me how this proposal interacts with extensions, especially ones which are not aware of new configuration backend 22:33:12 <AaronSchulz> but that is just for canonical storage, the apaches still need a copy locally 22:33:27 <TimStarling> legoktm: MySQL 22:33:42 <bd808> json is not the greatest config file format since it doesn't support comments 22:33:47 <AaronSchulz> b/c definitely needs mentioning in the rfc 22:33:50 <legoktm> vvv: you would still be able to use globals for backwards compatability 22:34:08 <legoktm> vvv: and extensions could use a hook to add their own configuration options 22:34:09 <robla> oh dear, bd808 is starting to hint at yaml 22:34:11 <qgil> #info <TimStarling> neither JSON nor CDB are really appropriate backends for a web interface 22:34:14 * robla grabs popcorn 22:34:21 <^d> Heh, so basically we're back to my old config proposal then. 22:34:24 <^d> Database. 22:34:39 <legoktm> Is using a database fast enough? 22:34:39 <vvv> YAML is what I've seen commonly used for those purposes 22:34:48 <robla> I believe Wikia has a db based solution. OwynD? 22:34:53 <AaronSchulz> legoktm: not without a local shared-nothing cache 22:35:14 <AaronSchulz> really lots of ways of doing canonical storage + local caching could work 22:35:17 * bd808 thinks robla is projecting just because I happen to maintain the best PHP YAML extension 22:35:21 <AaronSchulz> including using MySQL 22:35:46 <aude> legoktm: we stick php into local settings to do tricks, sometimes, like add a hook for a specific wiki 22:35:56 <aude> how would such things be handeld with the config db 22:35:56 <TimStarling> we need to have multiple backends merged together, right? 22:35:58 <aude> ? 22:36:15 <TimStarling> and for WMF, we only want a subset of configuration variables to be web-editable 22:36:17 <AaronSchulz> aude: yeah, config management works a lot better with declarative conf 22:36:30 <legoktm> aude: You would just stick that into LocalSettings.php like is currently done 22:36:33 <TimStarling> for things that are not web-editable, we want a source file in version control 22:36:36 <TimStarling> with comments 22:36:46 <AaronSchulz> things like $wgJobClasses would have some trickiness since extensions dynamically add on to it 22:36:56 <aude> legoktm: after extract globals or whatnot? 22:36:57 <TimStarling> for things that are web editable, we want logs with usernames, and diffs and such like 22:37:04 <Krenair> I was about to say - I'm wondering how web-editable things are going to work with extensions 22:37:26 <TimStarling> yeah, that's another thing, extensions are not mentioned in this new RFC 22:37:27 <legoktm> TimStarling: I was thinking that everything is stored in the backend, and we use userrights to restrict what gets edited on the web 22:37:51 <^d> re: extensions & how to present a UI & so forth, Daniel Kinzler had an idea on my last rf. 22:37:52 <legoktm> Krenair: what do you mean? 22:37:52 <^d> *rfc 22:38:01 <legoktm> aude: yes 22:38:18 <TimStarling> legoktm: you can't give the web user the ability to edit a file in version control 22:38:22 <AaronSchulz> if there was a convention that dynamically altered config vars were only a function of the core config plus the site json/whatever config plus extension presence I guess one could compile and distribute the config 22:38:32 <^d> https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/Configuration_database/Storing_setting_on_wiki_pages 22:38:51 <qgil> #link https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/Configuration_database/Storing_setting_on_wiki_pages 22:39:23 <AaronSchulz> if it was resolved down, you could even have the config code be isolated from the rest of MW and other things could read the config for different wikis 22:39:26 <legoktm> TimStarling: right. everything would be stored in the backend, just not everything would be web editable 22:40:01 <AaronSchulz> you also wouldn't need the horribleness of things like getCachedConfigVar() in JobQueueGroup 22:40:06 <legoktm> ^d: main problem with that is that its not easy to access another wiki's page text. there's also a security issue with non-public configs 22:40:26 <AaronSchulz> any rfc must deal with fetching foreign wiki configuration and extension altered config 22:40:34 <legoktm> AaronSchulz: sorry, i'm lost. what are you referring to? 22:40:41 <^d> Gives us an excuse to have an interwiki transclusion rfc ;-) 22:40:56 <TimStarling> well, the existing system gives us that for core conf vars 22:41:05 <TimStarling> we just forgot to account for extensions 22:41:09 <^d> Well, that's part of what I was advocating. 22:41:15 <^d> Start with the current system. 22:41:20 <^d> And incrementally make it better. 22:41:27 <TimStarling> the current system is moderately complex 22:41:32 <vvv> One of the issues I discovered some time ago, is that you can't really tell anything about extension config unless extensions are aware of your system 22:41:47 <TimStarling> it's not just a key/value store, it has post-processing, like $stdLogo 22:41:54 <AaronSchulz> we already resolve config down for caching in wmf-config sort of 22:42:04 <ori-l> what sort of abstraction would tie different json configuration blobs together? how would you navigate between them? 22:42:25 <ori-l> a 10k-line file is horrible, but you can follow it by scrolling up and down 22:42:39 <legoktm> ori-l: the current proposal just has it stored in one big json file 22:42:44 <legoktm> each organized by "category" 22:42:56 <ori-l> that doesn't seem that compelling to me 22:43:10 <legoktm> site related vars, RL related vars, etc. 22:43:46 <ori-l> JSON is very limited 22:43:52 <TimStarling> the current system has ways to apply settings to groups of wikis 22:43:53 <ori-l> you can't reference or compose values 22:44:01 <^d> TimStarling: Which is one thing you have to keep. 22:44:15 <legoktm> TimStarling: my proposal included using db lists 22:44:19 <^d> (And I always thought was the hardest part to get right if you do things from scratch) 22:45:09 <TimStarling> so we are talking about a global web UI? 22:45:37 <ori-l> legoktm: ? 22:45:49 <TimStarling> would there be a local UI, for non-WMF wikis? 22:46:03 <^d> I think talking about a UI is putting the cart before the horse when we can't even come to agreement on architecture. 22:46:13 <ori-l> I don't think so 22:46:17 <legoktm> I was really only thinking of a local UI 22:46:22 <legoktm> but there probably should be a global one 22:47:14 <TimStarling> I think we need to talk about requirements 22:47:22 <bd808> Why not just put everything in the db except enough bootstrap config to find the database? 22:47:42 <ori-l> What would that solve? 22:47:50 <TimStarling> I think our discussions on architecture are fairly directionless because we don't have clear requirements 22:48:25 <TimStarling> so, I would like to make that an action item and move on to the last RFC in the last 10 minutes of the meeting 22:48:28 <ori-l> I want to flag an additional issue 22:48:31 <ori-l> oh, go ahead. 22:48:42 <bd808> ori-l: Just trying to think of how editing would work I guess. Serializing to disk seems gross. 22:49:18 <qgil> #info <TimStarling> I think we need to talk about requirements 22:49:20 <TimStarling> #action legoktm and other interested devs to develop requirements list on wiki 22:49:27 <legoktm> ok 22:49:48 <qgil> #topic Text extraction 22:49:53 <MaxSem> Okay, so basically this RFC is asking for decisions on 2 things: core vs. extension and whether to store the extracts in page_props, unconditionally 22:50:00 <qgil> #link https://www.mediawiki.org/wiki/Requests_for_comment/Text_extraction 22:50:23 <qgil> #info <MaxSem> this RFC is asking for decisions on 2 things: core vs. extension and whether to store the extracts in page_props, unconditionally 22:50:44 <TimStarling> MaxSem: what is the total data size? 22:51:14 <TimStarling> we can't store much in page_props, increasing core database size is quite expensive 22:51:33 <MaxSem> HTML extracts are rendered pages minus 30-50% 22:51:47 <AaronSchulz> no core DB bloat please :) 22:51:49 <TimStarling> so, enormous? 22:51:50 <MaxSem> text extracts are much shorter than wikitext 22:51:50 <^d> Can we cache them $somewhere? 22:52:07 <^d> If we know we'll get a decent hit rate. 22:52:08 <aude> seems odd to mix that with other stuff in page props 22:52:22 <vvv> Wouldn't that fit well into whatever backend for parser cache we are currently using? 22:52:24 <aude> it's big enough to go in it's own place 22:52:35 <TimStarling> roughly how many bytes per page? 22:53:10 <MaxSem> not sure about the stats 22:53:30 <^d> You know where we could stash them...elasticsearch. 22:53:41 <^d> It would be kind of perfect for that. 22:53:48 <MaxSem> what for? 22:54:24 <MaxSem> ES is a search engine first of all, KV storage is btter done with something else 22:54:28 <TimStarling> MaxSem: the extension thing, you would have a WikitionaryExtract or WikimediaExtract extension or something like that? 22:54:29 <^d> We've already got text extracts (more or less) living in elasticsearch. 22:54:53 <MaxSem> TimStarling, say WIkimediaExtracts 22:54:57 <aude> it would be good not to have dependency on elastic search, but possibly as a "store" option 22:55:12 <MaxSem> but I was thinking about making it doable with config settings only 22:55:23 <^d> MaxSem: Indeed. You can search for a single document's extract ;-) 22:55:37 <^d> I think it should be in core, tbh 22:55:51 <MaxSem> ^d, I'm more interested in batch retrieval than in searching 22:56:03 <TimStarling> I was under the misapprehension that extracts were from truncated versions of articles 22:56:14 <TimStarling> that is not the case, there is no truncation, right? 22:56:26 <MaxSem> you can request a lede extract 22:56:31 <^d> MaxSem: Also doable. Give me pages [1,500] 22:56:31 <MaxSem> or first N sentences 22:56:45 <TimStarling> but the whole thing is stored somewhere? 22:57:05 <MaxSem> currently, it's cached in memcached 22:57:12 <^d> Meh, we only store current revisions though. 22:57:17 <^d> -10 :( 22:57:29 <bd808> Would stored parsoid DOMs make this easier? Just an xslt transform? 22:57:39 <MaxSem> but on-demand rendering doesn't allow batch retrieval 22:57:52 <TimStarling> #info extracts are definitely too big for the core DB, need some other storage backend 22:58:23 <MaxSem> TimStarling, extension DB like AFT and Echo? 22:58:42 <TimStarling> we don't have time today to go through all the options 22:58:55 <aude> MaxSem: i assume we'd have per-content type implementations of formatting, or even the option to opt-out for certain content types? 22:59:13 <MaxSem> aude, I'm only interested in articles 22:59:16 <aude> e.g. extracts for wikidata entities would be pretty different or perhaps not make sense 22:59:23 <aude> MaxSem: ok, so wikitext content 22:59:24 <TimStarling> it is quite a similar problem to what we are doing with ElasticSearch 22:59:31 <MaxSem> if someone has a different use case... patches welcome!:P 22:59:42 <TimStarling> let me do a couple of action items... 22:59:47 <^d> Indeed, which is what lead to HtmlFormatter making its way to core. 23:00:17 <TimStarling> #action MaxSem and other interested devs to discuss storage backend options on RFC 23:00:52 <TimStarling> #action ^d to comment on RFC sharing experience with similar problem in ElasticSearch 23:01:08 <MaxSem> anything on core vs. extension?:) 23:01:25 <TimStarling> it's fine by me to have WikimediaExtracts 23:01:30 <^d> Core makes it easier for me to reuse more for Cirrus 23:01:48 <^d> But if everyone else thinks extension I can live with it. 23:02:04 <qgil> Anything else? 23:02:08 <TimStarling> maybe you should say on the RFC what exactly will be in WikimediaExtracts and why it is needed 23:02:22 <MaxSem> I was proposing basics in core with possibly WMF-specific stuff in an ext 23:02:30 <aude> and make sure to mention which content type(s) :) 23:03:38 <aude> and that other content types could "hook" into this and implement the extracts in a different format 23:03:39 <TimStarling> ok, all done? 23:03:41 <MaxSem> aude, I liek getText() moar than getContent(), will use it until it disappears:P 23:03:53 <aude> hah 23:04:02 <qgil> Thank you everyone! The next meeting is scheduled on 2013-12-04, same time -- https://www.mediawiki.org/wiki/Architecture_meetings 23:04:06 <qgil> #endmeeting