Jump to content

Architecture meetings/RFC review 2014-04-23

From mediawiki.org

21:00-22:00 UTC at #wikimedia-office connect.

Requests for Comment to review

[edit]
  1. Requests for comment/Associated namespaces

Summary and logs

[edit]

Meeting summary & next actions

[edit]

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 .


  • Associated namespaces (sumanah, 21:02:37)


Meeting ended at 22:01:00 UTC.


Action items

[edit]
  • 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)

[edit]
  • 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

[edit]

See in HTML or see below.

Meeting logs


21:01:31 <sumanah> #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 <wm-labs-meetbot> 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 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:31 <wm-labs-meetbot> 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 <Micru> Hi James_F, glad to see you around!
21:01:37 <sumanah> #chair sumanah brion TimStarling
21:01:37 <wm-labs-meetbot> Current chairs: TimStarling brion sumanah
21:01:42 <sumanah> #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-23
21:01:49 <sumanah> #topic a few quick updates
21:01:54 <sumanah> OK, first -
21:01:59 <sumanah> #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 <sumanah> so check those out
21:02:37 <sumanah> #topic Associated namespaces
21:02:47 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces
21:02:59 <sumanah> #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 <sumanah> #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 <sumanah> that's the only RFC on our agenda today :)
21:03:48 * brion reads
21:04:26 <MaxSem> mmm, vagueish
21:04:34 <brion> it is a little vague to start
21:04:50 <brion> so generally i favor decoupling the assumption that namespaces come in (subject, talk) pairs which are even/odd adjacent integers
21:04:55 <brion> but that is hardcoded in a number of places
21:05:10 <brion> i’m not sure how hard it would be to totally change it with things like watchlist groupings
21:05:33 <sumanah> hey DanielK_WMDE_
21:05:33 <MaxSem> $title->getAssociatedNamespaces()
21:05:34 <brion> having a manager interface to register new namespaces/pairs/groups? hell yes please
21:05:44 <brion> we should not have to specify constants and tweak them manually
21:05:45 <DanielK_WMDE_> hi sumanah, MaxSem, brion!
21:05:51 <brion> those should go through a table
21:05:51 <sumanah> DanielK_WMDE_: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140423.txt we haven't talked much yet :)
21:05:56 <Micru> hi DanielK_WMDE_!
21:06:03 <DanielK_WMDE_> i'm a bit unprepared, sorry. what should i be looking at? the etherpad?
21:06:16 <DanielK_WMDE_> hi Micru!
21:06:30 <marktraceur> 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 <marktraceur> That's one caveat.
21:06:40 <James_F> Oh, yeah, very breaking.
21:06:42 <sumanah> DanielK_WMDE_: there's no etherpad that I know of :)
21:07:00 <sumanah> DanielK_WMDE_: https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces and the log I just mentioned would be good.
21:07:01 <marktraceur> Or we could force MediaWiki to always set the same IDs for the lower-level ones
21:07:05 <marktraceur> But ugly
21:07:16 <brion> there’s also the general issue of cross-wiki namespace number parity
21:07:28 <brion> which we have for built-in namespaces, but some of the extensions are kinda randomized
21:07:43 <brion> for folks doing bulk research it may be an issue to have the mappings wildly change
21:07:57 <brion> from lang to lang
21:08:04 <Micru> well, you could keep number parities for backward compability and enable a separate register for extra namespaces, would that make sense?
21:08:04 <marktraceur> brion: You mean cross-wiki within clusters?
21:08:19 <marktraceur> I see what you mean though
21:08:27 <brion> marktraceur: or in general working with db dumps or replicas and treating namespace ids
21:08:38 <brion> but it’s not too hard to join to another table and use the semantic name
21:08:42 <marktraceur> brion: Isn't that as simple as adding a JOIN? It would be added complexity, but all for the greater...yeah
21:09:27 <brion> yeah
21:09:56 <DanielK_WMDE_> 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 <marktraceur> No no no.
21:10:10 <DanielK_WMDE_> or do we just do away with any number magic?
21:10:16 <marktraceur> DanielK_WMDE_: What we're saying is the namespaces all get automatically assigned IDs
21:10:21 <marktraceur> Just auto-incremented
21:10:21 <brion> +1 is easy for pairs, but if we want to extend them that is totally gonna die
21:10:31 <DanielK_WMDE_> marktraceur: *all*, or custom/new ones?
21:10:36 <marktraceur> AFAIK all.
21:10:54 <marktraceur> 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 <marktraceur> 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 <marktraceur> 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 <brion> *nod*
21:12:26 <marktraceur> Similarly file pages will soon have (a) The file (b) metadata (c) talk
21:12:33 <marktraceur> Smaller example, but similar.
21:12:37 <James_F> Yes.
21:12:43 <James_F> (I picked the most complex.)
21:13:50 <marktraceur> 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 <marktraceur> 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 <brion> sensible
21:15:00 <brion> or we could just lock those NSs to their classic numbers
21:15:06 <marktraceur> Yeah
21:15:09 <DanielK_WMDE_> so, i'm totally sold on the use cases and concept
21:15:13 <brion> \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 <marktraceur> 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 <marktraceur> I guess we could just take a hammer to it
21:15:37 <DanielK_WMDE_> what namespaces should be defined initially?
21:15:49 <marktraceur> DanielK_WMDE_: db table seems like the best - it can get updated during update.php
21:15:58 <brion> i want to say db table, for the sanity of people researching in replicas
21:16:43 <brion> so we may need to make sure someone is carrying the flag on a design for this
21:16:45 <marktraceur> Or something. It feels less elegant to run inserts on the first page view, but we could do that too
21:16:50 <brion> or it might get forgotten.
21:17:06 <marktraceur> 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 <sumanah> 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 <marktraceur> #agreed use cases exist, concept is good
21:17:31 <sumanah> thanks marktraceur
21:17:33 <Micru> `marktraceur, I hope someone could volunteer, yes
21:17:45 <marktraceur> Micru: I mean, do you have any leads? :)
21:17:58 <brion> 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 <brion> but not sure exactly
21:18:33 <DanielK_WMDE_> brion: ...and aliases? default content model? some other kind of handler id?
21:18:35 <marktraceur> 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 <marktraceur> Aliases are a separate part of the code IMO
21:19:12 <brion> aliases are tricky too, they’re tied in with localizations etc
21:19:15 <brion> 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 <brion> 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 <marktraceur> 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 <brion> *nod*
21:20:31 <brion> i can see small wikis manually adding namespaces through a GUI
21:20:33 <James_F> Run-Once hook?
21:20:38 <brion> i can see extensions adding them in their update.php hooks
21:20:49 <brion> 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 <brion> a LocalSettings.php array does have certain advantages in that it’s our traditional admin interface
21:21:26 <brion> it has the disadvantage of being hard to edit programatically
21:21:27 <sumanah> 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 <brion> 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 <sumanah> ha
21:22:15 <sumanah> good
21:22:15 <DanielK_WMDE_> brion: four. puring caches.
21:22:15 <marktraceur> 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 <sumanah> Dantman: will you be in Zurich?
21:22:24 <brion> DanielK_WMDE_: d’oh, i was off by one ;)
21:22:26 <marktraceur> 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 <brion> so let’s maybe consider…
21:23:01 <brion> … a version that uses a config array
21:23:02 <Micru> marktraceur: sure, count me in as slave labour :D
21:23:08 <brion> … and think more on what it would look like if we did a table
21:23:20 <brion> 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 <brion> *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 <sumanah> Emufarmers: Isarra Lcawte hexmode - I do want your perspective on this from the non-Wikimedia MW administrator side
21:24:53 <sumanah> (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 <marktraceur> 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 <marktraceur> #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 <brion> advantage to the array is that it’s configured in the same place as existing namespace mechanisms
21:27:51 <brion> 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 <sumanah> yeah, I would love to hear from wikiHow, Wikia, et alia
21:28:13 <brion> 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 <brion> 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 <brion> 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 <sumanah> #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 <sumanah> #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 <brion> *nod* that’s a good start of an idea there
21:32:31 <sumanah> 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 <sumanah> 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 <sumanah> #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 <marktraceur> 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 <marktraceur> 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 <marktraceur> https://doc.wikimedia.org/mediawiki-core/master/php/html/classTitle.html#a17bd50bacfacf339375970d15860861a
21:38:37 <Emufarmers> hi
21:38:38 <marktraceur> "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 <marktraceur> Mind-readers man
21:39:04 <brion> :D
21:39:42 <marktraceur> 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 <marktraceur> 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 <sumanah> 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 <brion> *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 <marktraceur> 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 <rfarrand> 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 <sumanah> OK, we are 10 min from the end
21:50:30 <DanielK_WMDE_> the functio of ns0 is still "primary content"
21:50:32 <sumanah> TimStarling: haven't heard from you I think
21:50:43 <rfarrand> DanielK_WMDE_: almost time for a fun European reunion
21:50:50 <brion> 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 <marktraceur> 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 <sumanah> 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 <sumanah> 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 <sumanah> 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 <sumanah> #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 <sumanah> Fortunately today needed only a light touch :-)
22:01:00 <sumanah> #endmeeting
Retrieved from "https://www.mediawiki.org/w/index.php?title=Architecture_meetings/RFC_review_2014-04-23&oldid=980052"