[20:46:21] In 15 minutes in this channel, https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-23 we're talking about Micru's associated namespaces RfC [20:48:48] hi Micru [20:48:59] Micru: thank you for being here today [20:49:19] hi sumanah! thanks for organizing, I hope somebody else joins [20:49:58] * WikiPuppies arrives. [20:50:28] Bonjour, tout le monde. [20:50:59] Hi, WikiPuppies. I'm Sumana Harihareswara, a tech writer for Wikimedia Foundation and one of the people running this meeting [20:51:01] bonjour wikipuppies [20:51:11] WikiPuppies: I don't know if I've met you before. :-) Do you run your own wiki? [20:51:14] Pleasure to meet both of you. :) [20:51:43] sumanah: I've dabbled with MediaWiki, but I don't run any public wikis, no. [20:54:34] * marktraceur is here as promised :) [20:54:56] Thank you marktraceur [20:55:08] I know Daniel K is running late but will be here, as you requested, Micru [20:55:39] hex marktraceur, glad that you joined! [20:55:46] *hey [20:55:57] My pleasure :) [20:56:20] Micru: have you participated (or lurked) in one of these before? [20:57:05] sumanah, actually never! but I read some logs from past events [20:57:13] I'll announce a little bit of news about other RfCs, and then we'll talk about your RfC - I'll give a link and mention what you want out of today's discussion. We have the whole hour, since no one asked for the second half to discuss another proposal [20:57:40] sounds good to me [20:58:04] Great [20:58:22] Are there any other RfCs at https://www.mediawiki.org/wiki/Requests_for_comment that you think relate to yours in some way? [20:59:12] lemme take a look... [20:59:39] also Micru please be liberal about starting interesting sentences with #info so they're in the notes summary :-) [21:00:21] * marktraceur wishes there could be a #question tag [21:00:29] there sort of is? I think? [21:01:00] I guess #idea, but not really [21:01:08] Hey. [21:01:31] #startmeeting RfC review: associated namespaces | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours [21:01:31] Meeting started Wed Apr 23 21:01:31 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:31] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:32] The meeting name has been set to 'rfc_review__associated_namespaces___channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours' [21:01:32] Hi James_F, glad to see you around! [21:01:36] #chair sumanah brion TimStarling [21:01:37] Current chairs: TimStarling brion sumanah [21:01:42] #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-23 [21:01:49] #topic a few quick updates [21:01:54] OK, first - [21:01:59] #info We have some updates or new discussions on https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Simplify_thumbnail_cache , https://www.mediawiki.org/wiki/User:MarkTraceur/More_general_frontend_uploading_tools , https://www.mediawiki.org/wiki/Requests_for_comment/Reducing_image_quality_for_mobile , and https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework [21:02:18] so check those out [21:02:37] #topic Associated namespaces [21:02:47] #link https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces [21:02:58] #info Micru wants to find out whether there are any objections to the "Namespace registry and association handlers" that Mark proposed, discuss possible problems with his proposed approach, and see if there would be any hands available to work on it. [21:03:16] #info Micru mentioned that "I hope this RFC moves forward because it affects important upcoming and already deployed projects (Commons migration, templates, Visual editor, WD, etc)." [21:03:36] that's the only RFC on our agenda today :) [21:03:48] * brion reads [21:04:26] mmm, vagueish [21:04:34] it is a little vague to start [21:04:50] so generally i favor decoupling the assumption that namespaces come in (subject, talk) pairs which are even/odd adjacent integers [21:04:55] but that is hardcoded in a number of places [21:05:10] i’m not sure how hard it would be to totally change it with things like watchlist groupings [21:05:33] hey DanielK_WMDE_ [21:05:33] $title->getAssociatedNamespaces() [21:05:34] having a manager interface to register new namespaces/pairs/groups? hell yes please [21:05:44] we should not have to specify constants and tweak them manually [21:05:45] hi sumanah, MaxSem, brion! [21:05:51] those should go through a table [21:05:51] DanielK_WMDE_: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140423.txt we haven't talked much yet :) [21:05:56] hi DanielK_WMDE_! [21:06:03] i'm a bit unprepared, sorry. what should i be looking at? the etherpad? [21:06:17] hi Micru! [21:06:30] brion: It would be a breaking change, though, maybe? I'm almost certain I've written code that checked namespace IDs assuming they would always be the same. [21:06:38] That's one caveat. [21:06:40] Oh, yeah, very breaking. [21:06:41] DanielK_WMDE_: there's no etherpad that I know of :) [21:07:00] DanielK_WMDE_: https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces and the log I just mentioned would be good. [21:07:01] Or we could force MediaWiki to always set the same IDs for the lower-level ones [21:07:05] But ugly [21:07:16] there’s also the general issue of cross-wiki namespace number parity [21:07:28] which we have for built-in namespaces, but some of the extensions are kinda randomized [21:07:43] for folks doing bulk research it may be an issue to have the mappings wildly change [21:07:57] from lang to lang [21:08:03] well, you could keep number parities for backward compability and enable a separate register for extra namespaces, would that make sense? [21:08:04] brion: You mean cross-wiki within clusters? [21:08:19] I see what you mean though [21:08:27] marktraceur: or in general working with db dumps or replicas and treating namespace ids [21:08:38] but it’s not too hard to join to another table and use the semantic name [21:08:42] brion: Isn't that as simple as adding a JOIN? It would be added complexity, but all for the greater...yeah [21:09:27] yeah [21:09:56] the question is really whether we want to have any magic in the numbers. should "associated" namespaces always have odd numbers? or should we put "new" stuff at 1000000+$x ? [21:10:03] No no no. [21:10:10] or do we just do away with any number magic? [21:10:16] DanielK_WMDE_: What we're saying is the namespaces all get automatically assigned IDs [21:10:21] Just auto-incremented [21:10:21] +1 is easy for pairs, but if we want to extend them that is totally gonna die [21:10:31] marktraceur: *all*, or custom/new ones? [21:10:36] AFAIK all. [21:10:54] It's not that much extra work IMO to make the same system apply to the 20 or so existing core namespaces [21:10:56] i would recommend to stick to the well known IDs for the default namespaces for B/C [21:11:00] brion: For example, for Template: we want: (a) the template, (b) the documentation, (c) the meta-data, (d) the discussion. [21:11:03] at least per default. could be configurable [21:11:28] James_F: (e) the discussion of the documentation (f) the discussion of the metadata [21:11:41] marktraceur: Possibly, though I think those should be combined. [21:11:57] marktraceur: So three namespaces share one Flow-provided discussion namespace [21:12:01] Well, true. But the point is we should have a system powerful enough to let us do either way without much extra effort [21:12:05] Indeed. [21:12:21] *nod* [21:12:26] Similarly file pages will soon have (a) The file (b) metadata (c) talk [21:12:33] Smaller example, but similar. [21:12:37] Yes. [21:12:43] (I picked the most complex.) [21:13:50] DanielK_WMDE_: Back to the B/C concern...I think it's possibly a two-step process where e.g. 1.25 has the system in place for extended namespaces and 1.26 switches the core namespaces over to the new system too [21:14:09] In our usual two-steppin' deprecation pattern. [21:14:51] marktraceur: i don't see a benefit in not just keeping the old ids for well known namespaces. but i can be convinced :) [21:14:51] sensible [21:15:00] or we could just lock those NSs to their classic numbers [21:15:06] Yeah [21:15:09] so, i'm totally sold on the use cases and concept [21:15:13] \o/ [21:15:16] i'm only worried about the mechanism [21:15:25] db table or config array? [21:15:25] brion: I'm a little blurry in seeing how we could do this but I'm fine with reserving those IDs. [21:15:28] both/either? [21:15:34] I guess we could just take a hammer to it [21:15:37] what namespaces should be defined initially? [21:15:49] DanielK_WMDE_: db table seems like the best - it can get updated during update.php [21:15:58] i want to say db table, for the sanity of people researching in replicas [21:16:43] so we may need to make sure someone is carrying the flag on a design for this [21:16:45] Or something. It feels less elegant to run inserts on the first page view, but we could do that too [21:16:50] or it might get forgotten. [21:17:06] Is Micru looking at getting someone involved in the design and implementation? [21:17:09] db tables allow for easy joins, i guess [21:17:22] hexmode: hey there, would love your opinion on this in terms of 3rd parties' usage [21:17:25] but what should that db table actually contain? there is a lot of info that could potentially be associated with a namespace [21:17:26] #agreed use cases exist, concept is good [21:17:31] thanks marktraceur [21:17:33] `marktraceur, I hope someone could volunteer, yes [21:17:45] Micru: I mean, do you have any leads? :) [21:17:58] DanielK_WMDE_: i’d start with canonical name, id number, some sort of semantic markers… [21:18:01] not really, other than the people here tonight :) [21:18:08] a db table will need to be heavily cached for production use though. ideally in apc [21:18:11] but not sure exactly [21:18:33] brion: ...and aliases? default content model? some other kind of handler id? [21:18:35] DanielK_WMDE_: Yeah, I think it's just an ID to name table, it's nothing complicated. The association table would probably be separate. [21:18:43] DanielK_WMDE_: A problem with the N+1 is that it sets up a promise that we're not planning to keep. [21:18:54] Aliases are a separate part of the code IMO [21:19:12] aliases are tricky too, they’re tied in with localizations etc [21:19:15] bleh [21:19:21] also, how do users (and extensions!) define custom namespaces? [21:19:26] currently this is done via global arrays [21:19:45] updating a db table in just the right moment, in just the right way, is going to be tricky [21:19:46] right we’d want a consistent way to register, a nice api rather than ‘drop in the table’ [21:19:55] indeed [21:20:02] DanielK_WMDE_: Hooks? Is this inadequately helpful for people wanting to add them in LocalSettings? [21:20:14] api, maintenance script, run-once hook for extensions... [21:20:21] *nod* [21:20:31] i can see small wikis manually adding namespaces through a GUI [21:20:33] Run-Once hook? [21:20:38] i can see extensions adding them in their update.php hooks [21:20:49] i can see CLI scripts for mass operations on wiki farms like ours [21:20:54] marktraceur: for adding "custom" namespaces, LocalSettings is the most convenient way. And for B/C reasons, we somehow need to support the ones defined there [21:21:16] a LocalSettings.php array does have certain advantages in that it’s our traditional admin interface [21:21:26] it has the disadvantage of being hard to edit programatically [21:21:27] Micru: remind us - will you be at the Zurich hackathon? [21:21:30] brion: the current update.php hooks are not so pretty, and the errors caused by not running update.php non-obvious :( [21:21:30] NS_ constants are a problem. [21:21:48] Dantman: indeed, they are used everywhere, and have special meaning. [21:21:58] Dantman: If we deprecate them I don't see the problem. [21:22:00] I definitly vote for keepting the IDs for well known namespaces fixed [21:22:01] there are only three hard problems in computer science: naming things, off by one errors, and SCHEMA MIGRATIONS [21:22:11] sumanah - yes I'll be there [21:22:12] ha [21:22:15] good [21:22:15] DanielK_WMDE_: You can register hooks in ls.php, it's just a matter of writing a function instead of an array. My question is whether that's too complex or otherwise problematic. [21:22:16] brion: four. puring caches. [21:22:20] Dantman: will you be in Zurich? [21:22:24] DanielK_WMDE_: d’oh, i was off by one ;) [21:22:26] Micru: Maybe we can put our heads together and get something done, then :) [21:22:31] And we have a lot of things still doing comparison with getNamespace() [21:22:31] brion: lol! [21:22:33] sumanah: [21:22:34] DanielK_WMDE_, three becuse (2) [21:22:35] No [21:22:51] MaxSem: indeed [21:22:55] so let’s maybe consider… [21:23:01] … a version that uses a config array [21:23:02] marktraceur: sure, count me in as slave labour :D [21:23:08] … and think more on what it would look like if we did a table [21:23:20] if the table sounds super hard and the array fits better then let’s stay conservative [21:23:32] marktraceur: people already *have* custom namespaces defined there, and need a seamless migration path. [21:23:40] *nod* [21:24:02] so, update.php would look at the extra ns array, and feed it to the DB [21:24:29] in a later version, update.php could print a warning if there is still an extra ns array defined, because it will then no longer funktion (changing it will have no effect) [21:24:39] Emufarmers: Isarra Lcawte hexmode - I do want your perspective on this from the non-Wikimedia MW administrator side [21:24:53] (as I'm sure Micru does as well) [21:25:12] #agreed namespaces are defined in a database table [21:26:00] #info remaining issues: NS_ constants, migration of wgExtraNamespaces, what info to record about each NS (aliases, default content model, etc) [21:26:16] did i get this right? [21:26:42] Seems fine [21:26:57] brion: sorry, while i was writing this, i missed your suggestion about a version using a config array [21:27:01] Also remaining issue is non-WMF perspectives. [21:27:06] For NS_ constants/int comparison one thing I did some time ago was introduce $title->inNamespace and a few related methods. [21:27:11] so, how would that be better than a database table? [21:27:23] #info still looking for hexmode to comment on third party reusers' opinions [21:27:29] sumanah, I think important for non-wm admins is going to be the migration from the current model [21:27:34] advantage to the array is that it’s configured in the same place as existing namespace mechanisms [21:27:51] and doesn’t add db lookups/updates to the changing workflow [21:27:58] Dantman: how do you ask "is this title a category page"? [21:28:06] ...without using constants. [21:28:06] yeah, I would love to hear from wikiHow, Wikia, et alia [21:28:13] advantage of a table is that it may be more flexible in how it can be controlled, and is more useful for reusers of the schema (able to join to it) [21:28:50] but yeah we haev to decide whether things like content model sit in the table or in the config arrays, etc [21:29:10] #info SMW makes heavy use of custom namespaces. get input from e.g. Markus Krötsch or Jeroen De Dauw [21:29:19] and devise a good migration path, preferably which consists mostly of “do this one time and it creates the table, using your existing namespace numbers” [21:29:38] Dantman: instanceof/ [21:30:13] #action Micru SMW makes heavy use of custom namespaces, so get input from e.g. Markus Kr�tsch or Jeroen De Dauw :-) [21:30:26] sumanah: You pinged? [21:30:47] sumanah: yes, yes, I already put it on my to-do list ;) [21:30:55] #action Micru gather input from Owen Davis or other folks from Wikia, someone from wikiHow, hexmode or Markus Glaser to represent other third-party admins :-) [21:31:08] brion: +1 [21:31:56] DanielK_WMDE_: You still use them for now, the difference is that if you do $title->getNamespace() === NS_USER then the only thing you can do is a namespace number comparison, but if you do $title->inNamespace( NS_USER ) in the future NS_USER could become something like 'mw.user' and inNamespace could be accepting both string and legacy ids, or it could have a fixed compatibility map and shift away from numbers. The basic idea is that even if [21:32:30] *nod* that’s a good start of an idea there [21:32:31] Lcawte: We're discussing a possible change to namespaces and the author would like the input of people like you who run non-Wikimedia installations [21:32:48] Dantman: mw.user would be some kind of canonical name? Naw, we already have canonical names. use these. [21:33:20] Micru: Lcawte is the CTO for ShoutWiki http://www.shoutwiki.com/wiki/Technical_staff [21:33:32] i really don't like the idea of messing witrh the constants. they are used a gazillion times in extensions [21:34:13] keeping the canonical ids is important, i think. anything else will be a migration nightmare wrt the constants [21:34:22] #action Micru to spread word about this idea on the mediawiki-l list to ask extension developers for their input [21:34:32] changing the constants to strings will also bite us, i fear [21:34:56] DanielK_WMDE_: My experimentation was with a full namespace registry that handled core, extension, and site namespaces. Hence why I ended up with 'mw.user' [21:35:18] Dantman: why not just use "User"? [21:35:30] it *is* the caninical name, valid on any MW instance [21:36:00] sumanah, others: how scary do you want the email title to be? "Breaking change for extensions coming to your nearest MW" would do? :) [21:36:26] I mean, it's not so imminent [21:36:39] Micru: "Proposed breaking change in MediaWiki namespace architecture"? [21:36:49] Micru: how about making this a non-breaking change?... [21:37:11] I don't think it necessarily has to be breaking [21:37:13] DanielK_WMDE_: Yeah changing the constants might not be the best idea. An alternative might be to add a fixed string -> id map inside core and make it so that ->inNamespace( '...' ) will work, then deprecate id comparisons and switch to a registry later on. [21:37:37] Dantman: why deprecate ID comparison? [21:37:41] pieces of code that don't want to care about associations can continue doing so [21:37:45] if we have well known IDs, we can keep using them [21:37:49] no need to change that [21:37:50] Isn't ID comparison already deprecated? [21:38:07] Yes. [21:38:09] I thought? [21:38:10] ok, ok, then I will drop the word "breaking"... [21:38:29] https://doc.wikimedia.org/mediawiki-core/master/php/html/classTitle.html#a17bd50bacfacf339375970d15860861a [21:38:37] hi [21:38:38] "Please make use of this instead of comparing to getNamespace() This function is much more resistant to changes we may make to namespaces than code that makes direct comparisons. " [21:38:42] Micru: the important bit is to actually make sure it doesn't break anything :) [21:38:43] Mind-readers man [21:39:03] :D [21:39:42] DanielK_WMDE_: Programming would be so much more fun if things didn't have to keep working all the time... :) [21:40:25] ack-grep -l '== *NS_' includes/ | wc -l [21:40:35] i see 58 direct comparisons in core [21:40:51] marktraceur: I introduced that method but I'm not sure it's really been adopted by people yet. [21:40:54] DanielK_WMDE_: well, then it will be "Proposed change and transition in MediaWiki namespace architecture" [21:41:23] Micru: "namespace" is ambiguous, say "page namespaces" or something [21:41:26] Dantman: It has, but getNamespace might still be used a bunch [21:41:37] * DanielK_WMDE_ wants php namespaces used in core [21:41:43] for those of us without a checkout on our local machines, http://hexm.de/mw-search [21:41:44] DanielK_WMDE_: thanks for the advice! [21:42:21] marktraceur: and get rid of the pesky users, too! they just break stuff and get confused. [21:42:31] * sumanah wants us to run an installation of DXR like http://dxr.mozilla.org [21:42:32] DanielK_WMDE_: 58 is easy to fix. [21:42:42] James_F: plus all the extensions [21:42:46] DanielK_WMDE_: Hey, careful! :) [21:42:55] ...in a way that works with old and new core... ick. [21:42:57] DanielK_WMDE_: I've fixed 300+ jslint failures. [21:43:18] DanielK_WMDE_: It's tedious, but it's doable if it's the right thing to do. [21:43:29] James_F: i don't see the need [21:43:48] direct comparison with constants is done for well known namespaces. why not just keep these? [21:43:56] it's easily done, and saves a lot of pain [21:44:37] DanielK_WMDE_: If you want an extension to take over a namespace (e.g. a new Category: system) NS registry could theoretically allow it. [21:45:08] DanielK_WMDE_: re: 'User', the pattern I was working with included things like 'mw.user', 'ext.smw.property' (or a full extension name instead of 'smw'), and 'site.*'. 'User' isn't enough. There are always present core namespaces 'mw.*'. Extension namespaces 'ext.*.*' which need to ensure that they do not conflict with other extensions nor core, and custom site namespaces 'site.*' which you don't want to collide with extensions and may not hav [21:45:12] James_F: "take over" how? it could register a handler for deailign with such pages. no need to change the id. [21:45:22] that actually makes more sense semantically [21:46:08] basically, for a well known canonical name, you get the well known canonical id. assigning a different ID to thouse would be illegal and trigger an error. [21:46:11] not hard [21:46:19] *nod* keep the id, replace the handler makes sense [21:46:29] What if it has a different type? [21:46:45] James_F: "type" as in what? [21:46:45] James_F: I'm holding off on #action James_F Remove direct NS_ constant comparisons in core [21:46:48] NS_CATEGORY => wikitext, but NS_NEW_KIND_OF_CATEGORY => wikibase (or whatever)? [21:46:51] marktraceur: :-) [21:47:19] James_F: you can already override the content model for any namespace. wikidata has data items i nthe main NS [21:47:20] If we encourage lazy assumptions that NS_ comparsions are OK, we're inviting lazy assumptions about CH status of those namespaces. [21:47:48] * James_F shrugs. [21:47:57] Btw, here's the code I was playing with when experimenting on implementing the namespace registry [21:47:58] https://github.com/dantman/mediawiki-core/compare/master...namespace-registry [21:48:01] James_F: well known namespaces have well known semantics. [21:48:15] "category", "file", "user" etc are *functions* of namespaces. [21:48:35] DanielK_WMDE_: Which is why I'm suggesting making people think twice about whether well-known namespaces are going to be around and work as expected. [21:48:36] they would be assigned to additional namespaces, but it shouldn't be possible to take them away from the current default namespaces [21:48:53] hey rfarrand! [21:49:22] James_F: i think allowing people to change the *function* of default namespaces is a bad idea. but i see you point: [21:49:39] if i want to know whther a namespace is a category namespace, == NS_CATEGORy would no longer be sufficient [21:49:44] DanielK_WMDE_: Isn't the function of the default namespace exactly what wikibase did for NS0? [21:50:02] i'd have to use Namespace::isCategory( $ns ) [21:50:06] DanielK_WMDE_: Hi! [21:50:07] DanielK_WMDE_: wikidata.org/wiki/Special:Random?action=edit [21:50:15] James_F: we changed the content model, not the function [21:50:24] OK, we are 10 min from the end [21:50:30] the functio of ns0 is still "primary content" [21:50:32] TimStarling: haven't heard from you I think [21:50:43] DanielK_WMDE_: almost time for a fun European reunion [21:50:50] gotta run charge, brb [21:51:08] Micru: i think the notion of semantics/functionality of a namespace, beyond the content model, needs some thought / explicit modelling. [21:51:21] rfarrand: yes! awesome! [21:52:29] #info the notion of semantics/functionality of a namespace, beyond the content model, needs some thought / explicit modelling. [21:52:30] DanielK_WMDE_: namespace functionality has always been open for experimentation.... why to limit it? [21:53:04] Micru: i don't want to limit it. I only want to keep it fixed for the existing standard namespaces [21:53:38] you can still override the content model and the way such pages are rendered [21:54:37] Micru: the user namespace is implicitly mapped to the user table. the category namespace is implicit in the categorylinks table (can't have multiple category namespaces work with that at the moment) [21:54:49] the file namespace is implicitly mapped to the image table [21:54:51] etc [21:54:52] DanielK_WMDE_: That sounds like a limit, though. [21:54:54] DanielK_WMDE_: do you mean that it would be necessary to define what a namespace does? [21:55:11] Like now "odd number = talk page"? [21:55:11] Micru: if it does anything "special", yes [21:55:38] Micru: yes, but more importantly file, category, mediawiki, and user. [21:56:09] we can/should drop "odd -> talk", i guess. [21:56:12] DanielK_WMDE_: and what about "talk" and "custom"? [21:56:39] "talk" is a function, but shouldn't be bound to numeric magic (except for default namespaces) [21:56:43] Especially since we may not want a talk namespace for every namespace [21:56:48] Indeed. [21:56:59] Ok. [21:57:00] And we may want to get rid of talk even for some default namespaces. [21:57:08] "custom" isn't useful, custom namespaces should make up custom functions if they want, and use existing functions ("text") if possible. [21:57:20] (As an option.) [21:57:38] James_F: possibly... but... can't think of any where that makes sense. [21:57:59] Any more #info or #agreed or #idea or #action stuff? [21:58:01] (Special: already doesn#t have a talk NS) [21:58:09] DanielK_WMDE_: Special: isn't an NS. :-) [21:58:12] We should wrap up, as I'm sure some people have to go at the end of the hour [21:58:14] Yeah. [21:58:16] DanielK_WMDE_, what would use WD? [21:58:19] Nothing more from me. [21:58:23] James_F: yes it is. [21:59:19] Micru: could be "data" or "item" and "property", respectively. [21:59:35] ns0 might be fixed to "content". [21:59:57] DanielK_WMDE_: ok, I get the idea [21:59:59] maybe the notion of a "function" is only usefule for the stuff core treats specially [22:00:07] We gotta go [22:00:13] My thoughts for awhile have been that special purposes like category, mediawiki, user get attached to the canonical string, talk becomes a namespace relation in the db, and for back compat the code in charge of registration keeps the id patterns around (old core ns numbers, odd/even talk/content, and negative specials), but use of the ns number becomes deprecated. [22:00:23] #info next week - https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_libraries and possibly also https://www.mediawiki.org/wiki/Requests_for_comment/Third-party_components [22:00:42] sumanah: thanks for moderating"! [22:00:54] Fortunately today needed only a light touch :-) [22:01:00] #endmeeting [22:01:01] Meeting ended Wed Apr 23 22:01:00 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:01:01] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-23-21.01.html [22:01:01] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-23-21.01.txt [22:01:01] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-23-21.01.wiki [22:01:01] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-23-21.01.log.html [22:01:03] thanks all for participating, thanks sumanah for the moderation! [22:01:50] Glad to help. Micru check out https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-23-21.01.txt for a lot of stuff for you to do :-) [22:02:44] sumanah, yummy homework :) [22:02:49] :) [22:03:11] but for now I go to sleep, good night! [22:03:29] Night! [22:03:31] ugh, seems like i talk to much... look at the line count! [22:03:33] * DanielK_WMDE_ hides [22:04:30] it's ok DanielK_WMDE_ :) [22:14:07] ok, the meeting wiki page now has notes on it [22:14:26] DanielK_WMDE_: it is good that you talked - the author wanted your opinion! [22:55:42] Someone should tell sumanah that non-wikimedia folks have a harder time showing up to these things because they tend to happen when we're at work ourselves.