Architecture meetings/RFC review 2014-04-23

21:00-22:00 UTC at.

Requests for Comment to review

 * 1) Requests for comment/Associated namespaces

Meeting summary & next actions
Meeting started by sumanah at 21:01:31 UTC. The full logs are available at https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-23-21.01.log.html .


 * LINK: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-23 (sumanah, 21:01:42)
 * a few quick updates (sumanah, 21:01:49)
 * 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 (sumanah, 21:01:59)


 * Associated namespaces (sumanah, 21:02:37)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces (sumanah, 21:02:47)
 * 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. (sumanah, 21:02:59)
 * 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)." (sumanah, 21:03:16)
 * remaining issues: NS_ constants, migration of wgExtraNamespaces, what info to record about each NS (aliases, default content model, etc) (DanielK_WMDE_, 21:26:00)
 * still looking for hexmode to comment on third party reusers' opinions (marktraceur, 21:27:23)
 * SMW makes heavy use of custom namespaces. get input from e.g. Markus Krötsch or Jeroen De Dauw (DanielK_WMDE_, 21:29:09)
 * ACTION: Micru SMW makes heavy use of custom namespaces, so get input from e.g. Markus Kr�tsch or Jeroen De Dauw :-) (sumanah, 21:30:14)
 * 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 :-) (sumanah, 21:30:55)
 * ACTION: Micru to spread word about this idea on the mediawiki-l list to ask extension developers for their input (sumanah, 21:34:22)
 * LINK: https://doc.wikimedia.org/mediawiki-core/master/php/html/classTitle.html#a17bd50bacfacf339375970d15860861a (marktraceur, 21:38:29)
 * LINK: https://github.com/dantman/mediawiki-core/compare/master...namespace-registry (Dantman, 21:47:58)
 * the notion of semantics/functionality of a namespace, beyond the content model, needs some thought / explicit modelling. (DanielK_WMDE_, 21:52:29)
 * 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 (sumanah, 22:00:24)

Meeting ended at 22:01:00 UTC.

Action items

 * Micru SMW makes heavy use of custom namespaces, so get input from e.g. Markus Kr�tsch or Jeroen De Dauw :-)
 * Micru gather input from Owen Davis or other folks from Wikia, someone from wikiHow, hexmode or Markus Glaser to represent other third-party admins :-)
 * Micru to spread word about this idea on the mediawiki-l list to ask extension developers for their input

People present (lines said)

 * DanielK_WMDE_ (98)
 * brion (50)
 * marktraceur (42)
 * sumanah (40)
 * James_F (34)
 * Micru (20)
 * Dantman (13)
 * MaxSem (5)
 * wm-labs-meetbot (4)
 * rfarrand (2)
 * WikiPuppies (1)
 * Lcawte (1)
 * Emufarmers (1)
 * TimStarling (0)

Generated by MeetBot 0.1.4 (http://wiki.debian.org/MeetBot)

Full log
See in HTML or see below.

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:31  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:31  Hi James_F, glad to see you around! 21:01:37 #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:19 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:59 #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:16  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:42 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:04  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 <DanielK_WMDE_> i would recommend to stick to the well known IDs for the default namespaces for B/C 21:11:00 <James_F> brion: For example, for Template: we want: (a) the template, (b) the documentation, (c) the meta-data, (d) the discussion. 21:11:03 <DanielK_WMDE_> 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 <James_F> marktraceur: Possibly, though I think those should be combined. 21:11:57 <James_F> 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 <James_F> 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 <James_F> Yes. 21:12:43 <James_F> (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:50 <DanielK_WMDE_> 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 <DanielK_WMDE_> so, i'm totally sold on the use cases and concept 21:15:13 \o/ 21:15:16 <DanielK_WMDE_> i'm only worried about the mechanism 21:15:25 <DanielK_WMDE_> 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:27 <DanielK_WMDE_> both/either? 21:15:34 I guess we could just take a hammer to it 21:15:37 <DanielK_WMDE_> 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 <DanielK_WMDE_> 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 <DanielK_WMDE_> 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 <Micru> `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 <Micru> not really, other than the people here tonight :) 21:18:07 <DanielK_WMDE_> 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 <DanielK_WMDE_> 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 <James_F> 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 <DanielK_WMDE_> also, how do users (and extensions!) define custom namespaces? 21:19:26 <DanielK_WMDE_> currently this is done via global arrays 21:19:45 <DanielK_WMDE_> 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 <DanielK_WMDE_> indeed 21:20:02 DanielK_WMDE_: Hooks? Is this inadequately helpful for people wanting to add them in LocalSettings? 21:20:14 <DanielK_WMDE_> 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 <James_F> 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 <DanielK_WMDE_> 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 <DanielK_WMDE_> brion: the current update.php hooks are not so pretty, and the errors caused by not running update.php non-obvious :( 21:21:30 <Dantman> NS_ constants are a problem. 21:21:48 <DanielK_WMDE_> Dantman: indeed, they are used everywhere, and have special meaning. 21:21:57 <James_F> Dantman: If we deprecate them I don't see the problem. 21:22:00 <DanielK_WMDE_> 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 <Micru> sumanah - yes I'll be there 21:22:12 ha 21:22:15 good 21:22:15 <DanielK_WMDE_> brion: four. puring caches. 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: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 <Dantman> And we have a lot of things still doing comparison with getNamespace 21:22:31 <DanielK_WMDE_> brion: lol! 21:22:33 <Dantman> sumanah: 21:22:34 <MaxSem> DanielK_WMDE_, three becuse (2) 21:22:35 <Dantman> No 21:22:51 <DanielK_WMDE_> MaxSem: indeed 21:22:55 so let’s maybe consider… 21:23:01 … a version that uses a config array 21:23:02 <Micru> 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:31 <DanielK_WMDE_> marktraceur: people already *have* custom namespaces defined there, and need a seamless migration path. 21:23:40 *nod* 21:24:02 <DanielK_WMDE_> so, update.php would look at the extra ns array, and feed it to the DB 21:24:29 <DanielK_WMDE_> 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 <DanielK_WMDE_> #agreed namespaces are defined in a database table 21:26:00 <DanielK_WMDE_> #info remaining issues: NS_ constants, migration of wgExtraNamespaces, what info to record about each NS (aliases, default content model, etc) 21:26:15 <DanielK_WMDE_> did i get this right? 21:26:42 Seems fine 21:26:57 <DanielK_WMDE_> brion: sorry, while i was writing this, i missed your suggestion about a version using a config array 21:27:01 <James_F> Also remaining issue is non-WMF perspectives. 21:27:06 <Dantman> For NS_ constants/int comparison one thing I did some time ago was introduce $title->inNamespace and a few related methods. 21:27:11 <DanielK_WMDE_> 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 <Micru> 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 <DanielK_WMDE_> Dantman: how do you ask "is this title a category page"? 21:28:06 <DanielK_WMDE_> ...without using constants. 21:28:07 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:09 <DanielK_WMDE_> #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 <James_F> Dantman: instanceof/ 21:30:14 #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 <Lcawte> sumanah: You pinged? 21:30:47 <Micru> 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 <DanielK_WMDE_> brion: +1 21:31:56 <Dantman> 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 <DanielK_WMDE_> 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 <DanielK_WMDE_> i really don't like the idea of messing witrh the constants. they are used a gazillion times in extensions 21:34:13 <DanielK_WMDE_> 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 <DanielK_WMDE_> changing the constants to strings will also bite us, i fear 21:34:56 <Dantman> 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 <DanielK_WMDE_> Dantman: why not just use "User"? 21:35:30 <DanielK_WMDE_> it *is* the caninical name, valid on any MW instance 21:36:00 <Micru> 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 <James_F> Micru: "Proposed breaking change in MediaWiki namespace architecture"? 21:36:49 <DanielK_WMDE_> Micru: how about making this a non-breaking change?... 21:37:11 <MaxSem> I don't think it necessarily has to be breaking 21:37:13 <Dantman> 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 <DanielK_WMDE_> Dantman: why deprecate ID comparison? 21:37:41 <MaxSem> pieces of code that don't want to care about associations can continue doing so 21:37:45 <DanielK_WMDE_> if we have well known IDs, we can keep using them 21:37:49 <DanielK_WMDE_> no need to change that 21:37:50 Isn't ID comparison already deprecated? 21:38:07 <James_F> Yes. 21:38:09 <James_F> I thought? 21:38:10 <Micru> 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 <Emufarmers> 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:41 <DanielK_WMDE_> Micru: the important bit is to actually make sure it doesn't break anything :) 21:38:43 Mind-readers man 21:39:04 :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 <DanielK_WMDE_> ack-grep -l '== *NS_' includes/ | wc -l 21:40:35 <DanielK_WMDE_> i see 58 direct comparisons in core 21:40:51 <Dantman> marktraceur: I introduced that method but I'm not sure it's really been adopted by people yet. 21:40:54 <Micru> DanielK_WMDE_: well, then it will be "Proposed change and transition in MediaWiki namespace architecture" 21:41:22 <DanielK_WMDE_> 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 <Micru> DanielK_WMDE_: thanks for the advice! 21:42:20 <DanielK_WMDE_> 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 <James_F> DanielK_WMDE_: 58 is easy to fix. 21:42:42 <DanielK_WMDE_> James_F: plus all the extensions 21:42:47 <WikiPuppies> DanielK_WMDE_: Hey, careful! :) 21:42:55 <DanielK_WMDE_> ...in a way that works with old and new core... ick. 21:42:57 <James_F> DanielK_WMDE_: I've fixed 300+ jslint failures. 21:43:18 <James_F> DanielK_WMDE_: It's tedious, but it's doable if it's the right thing to do. 21:43:29 <DanielK_WMDE_> James_F: i don't see the need 21:43:48 <DanielK_WMDE_> direct comparison with constants is done for well known namespaces. why not just keep these? 21:43:56 <DanielK_WMDE_> it's easily done, and saves a lot of pain 21:44:37 <James_F> 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 <Dantman> 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 <DanielK_WMDE_> James_F: "take over" how? it could register a handler for deailign with such pages. no need to change the id. 21:45:22 <DanielK_WMDE_> that actually makes more sense semantically 21:46:08 <DanielK_WMDE_> 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 <DanielK_WMDE_> not hard 21:46:19 *nod* keep the id, replace the handler makes sense 21:46:29 <James_F> What if it has a different type? 21:46:45 <DanielK_WMDE_> James_F: "type" as in what? 21:46:46 James_F: I'm holding off on #action James_F Remove direct NS_ constant comparisons in core 21:46:48 <James_F> NS_CATEGORY => wikitext, but NS_NEW_KIND_OF_CATEGORY => wikibase (or whatever)? 21:46:51 <James_F> marktraceur: :-) 21:47:18 <DanielK_WMDE_> James_F: you can already override the content model for any namespace. wikidata has data items i nthe main NS 21:47:20 <James_F> 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 <Dantman> Btw, here's the code I was playing with when experimenting on implementing the namespace registry 21:47:58 <Dantman> https://github.com/dantman/mediawiki-core/compare/master...namespace-registry 21:48:01 <DanielK_WMDE_> James_F: well known namespaces have well known semantics. 21:48:15 <DanielK_WMDE_> "category", "file", "user" etc are *functions* of namespaces. 21:48:35 <James_F> 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 <DanielK_WMDE_> 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 <DanielK_WMDE_> hey rfarrand! 21:49:22 <DanielK_WMDE_> 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 <DanielK_WMDE_> if i want to know whther a namespace is a category namespace, == NS_CATEGORy would no longer be sufficient 21:49:44 <James_F> DanielK_WMDE_: Isn't the function of the default namespace exactly what wikibase did for NS0? 21:50:01 <DanielK_WMDE_> i'd have to use Namespace::isCategory( $ns ) 21:50:06 DanielK_WMDE_: Hi! 21:50:07 <James_F> DanielK_WMDE_: wikidata.org/wiki/Special:Random?action=edit 21:50:15 <DanielK_WMDE_> James_F: we changed the content model, not the function 21:50:24 OK, we are 10 min from the end 21:50:30 <DanielK_WMDE_> 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 <DanielK_WMDE_> Micru: i think the notion of semantics/functionality of a namespace, beyond the content model, needs some thought / explicit modelling. 21:51:21 <DanielK_WMDE_> rfarrand: yes! awesome! 21:52:29 <DanielK_WMDE_> #info the notion of semantics/functionality of a namespace, beyond the content model, needs some thought / explicit modelling. 21:52:30 <Micru> DanielK_WMDE_: namespace functionality has always been open for experimentation.... why to limit it? 21:53:03 <DanielK_WMDE_> Micru: i don't want to limit it. I only want to keep it fixed for the existing standard namespaces 21:53:38 <DanielK_WMDE_> you can still override the content model and the way such pages are rendered 21:54:37 <DanielK_WMDE_> 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 <DanielK_WMDE_> the file namespace is implicitly mapped to the image table 21:54:51 <DanielK_WMDE_> etc 21:54:52 <James_F> DanielK_WMDE_: That sounds like a limit, though. 21:54:54 <Micru> DanielK_WMDE_: do you mean that it would be necessary to define what a namespace does? 21:55:11 <DanielK_WMDE_> Micru: if it does anything "special", yes 21:55:11 <Micru> Like now "odd number = talk page"? 21:55:38 <DanielK_WMDE_> Micru: yes, but more importantly file, category, mediawiki, and user. 21:56:08 <DanielK_WMDE_> we can/should drop "odd -> talk", i guess. 21:56:12 <Micru> DanielK_WMDE_: and what about "talk" and "custom"? 21:56:38 <DanielK_WMDE_> "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 <James_F> Indeed. 21:56:59 <Micru> Ok. 21:57:00 <James_F> And we may want to get rid of talk even for some default namespaces. 21:57:08 <DanielK_WMDE_> "custom" isn't useful, custom namespaces should make up custom functions if they want, and use existing functions ("text") if possible. 21:57:20 <James_F> (As an option.) 21:57:38 <DanielK_WMDE_> 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:00 <DanielK_WMDE_> (Special: already doesn#t have a talk NS) 21:58:09 <James_F> 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 <James_F> Yeah. 21:58:16 <Micru> DanielK_WMDE_, what would use WD? 21:58:19 <James_F> Nothing more from me. 21:58:23 <DanielK_WMDE_> James_F: yes it is. 21:59:19 <DanielK_WMDE_> Micru: could be "data" or "item" and "property", respectively. 21:59:35 <DanielK_WMDE_> ns0 might be fixed to "content". 21:59:57 <Micru> DanielK_WMDE_: ok, I get the idea 21:59:59 <DanielK_WMDE_> maybe the notion of a "function" is only usefule for the stuff core treats specially 22:00:07 We gotta go 22:00:14 <Dantman> 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:24 #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:41 <DanielK_WMDE_> sumanah: thanks for moderating"! 22:00:54 Fortunately today needed only a light touch :-) 22:01:00 #endmeeting