22:03:58 <meetbot-wm`> Meeting started Wed Nov 6 22:03:58 2013 UTC. The chair is qgil. Information about MeetBot at https://bugzilla.wikimedia.org/46377.
22:06:45 <DanielK_WMDE_> hm, am i supposed to say something about TitleValue now?
22:06:47 <TimStarling> were there any unresolved issues from the mailing list discussion that anyone would like to raise now?
22:06:47 <qgil> (thank you bd808 - fyi everybody, if you want a sentence to appear in the notes, start with #info bla bla )
22:06:59 <^d> TimStarling: Yes, one of the major unresolved issues was serialization.
22:07:05 <brion> so I love the idea of TitleValue itself; I'm a bit less sold on TitleParser and TitleFormatter and the registry, but talk me into it :)
22:07:11 <^d> I think there was some unresolved question as to how we'd store namespaces.
22:07:20 <^d> Whether it'd be an int, or the canonical name, etc.
22:07:39 <TimStarling> what would you use serialization for?
22:08:33 <brion> other than 'happening to be a member of an object that gets serialized'Â ?
22:08:55 <TimStarling> we don't really serialize objects very often
22:09:26 <DanielK_WMDE_> serialization is not the point
22:09:50 <TimStarling> as for integer versus canonical namespace, integer seems the obvious choice to me
22:09:54 <DanielK_WMDE_> basically, it's about this: almost everythin uses Title, directly or indirectly. So, to avoid a tangle, Title should depend on very little.
22:10:06 <brion> i'd say there's two prime possibilities:
22:10:08 <brion> 1) use the integer key
22:10:09 <TimStarling> since everything about a namespace can easily be determined from its integer ID
22:10:13 <brion> 2) use a MWNamespace object
22:10:13 <DanielK_WMDE_> but in reality, Title relies on a bunch of things - and thus, everything depends on everything.
22:10:20 <DanielK_WMDE_> This turns mediaWiki into a monolithic tangle.
22:10:33 <brion> but life is simplest if we just store an int eh :D
22:10:54 <^d> I'm fine with ints too :)
22:11:02 * MaxSem scrolls to the bottom of Tite.php and sees getEditNotices():/
22:11:10 <TimStarling> MWNamespace depends on everything, right?
22:11:30 <DanielK_WMDE_> using a canonical namespace has the advantage that we can meaningfully represent titles from other wikis
22:11:34 <DanielK_WMDE_> with IDs, we can't do that
22:11:58 <MaxSem> I think we'll end up storing title proper, ns number and ns string
22:12:09 <aude> MWNamespace is a utility class
22:12:14 <TimStarling> DanielK_WMDE_: that application is not discussed on the RFC, is it?
22:12:14 <DanielK_WMDE_> which is better really depends on what we want to use the TitleValue for: if we want to generate a link, it's nicer to have the namespace name. if we want to run a DB query, it's nicer to have the id.
22:12:15 <aude> doesn't make sense to mix them
22:12:29 <DanielK_WMDE_> TimStarling: no, it only ocurred to me recently.
22:12:33 <TimStarling> I think you can use integers for foreign titles, if you want to
22:12:57 <TimStarling> it is a bit more complicated than what we do now
22:13:01 <DanielK_WMDE_> TimStarling: but then how do you generate a link? you'd need to know the id->name mapping for the namespaces on the other wiki
22:13:11 <TimStarling> which is NS=0 DBK=<foreign PDBK>
22:13:19 <brion> DanielK_WMDE_: so we really can't do id->name or name->id mapping on foreign wikis without fetching their remote configuration
22:13:29 <DanielK_WMDE_> indeed
22:13:30 <brion> *nod* that's about how we handle interwikis now
22:13:31 <TimStarling> yes, I mean by fetching the remote configuration
22:14:19 <DanielK_WMDE_> on the other hand, there's nothing that forces us to not have a calss other than TitleValue to handle these cases. In factm I proposed WikiLink for this.
22:14:21 <bawolff> Interwikis also don't necessarily point to wikis
22:14:34 <TimStarling> DanielK_WMDE_: what do you think of Brad's criticism that TitleParser and TitleFormatter could be the same class?
22:14:50 <DanielK_WMDE_> yes, that would only work for other mediawiki instances. so perhaps a WikiLink class would be more useful for that.
22:15:31 <DanielK_WMDE_> TimStarling: i think the *interfaces* should be independent, but they could be implemented by the same class.
22:15:33 <TimStarling> I think interwiki links to non-wikis were a terrible mistake
22:15:39 <TimStarling> in fact, I think the whole interwiki feature sucks
22:15:43 <DanielK_WMDE_> but code using these should not *rely* on them being implemented by the same class or object
22:15:44 <TimStarling> but maybe that's a rant for another day
22:15:45 <aude> +1 seems weird to represent non-mediawiki "titles" with title values
22:16:03 * brion hmms
22:16:14 <csteipp> I actually support Brad in that. Both the parsing and the formatting will have a security component, and I'd rather *not* see the security distributed across many objects.
22:16:20 <brion> i hate to suggest Interfaces but .... could we have TitleVaue and ForeignTitle? or is that way MADNESS
22:17:05 <brion> so I'd tend to wrap TitleParser and TitleFormatter together also
22:17:06 <TimStarling> what do we use foreign titles for at the moment?
22:17:09 <DanielK_WMDE_> brion: ForeignTitle is pretty much what i ment when i wrote this into the rfc: "a WikiLink class with subclasses for internal links, interwiki links, and external links."
22:17:16 <aude> TimStarling: extensively with wikibase
22:17:38 <DanielK_WMDE_> aude: using our own (Simple)SiteLink class.
22:18:10 <TimStarling> aude: you use Title objects with interwiki prefixes in wikibase?
22:18:11 <aude> DanielK_WMDE_: figuring out the namespace for the link is the tricky part
22:18:17 <DanielK_WMDE_> TimStarling: im'n not sure how often Title objects are used to represent interwiki links... but the introduction of TitleValue wouldn't hinder that.
22:18:23 <AaronSchulz> brion: seems like they could be one yeah
22:18:38 <aude> TimStarling: we use site links
22:18:53 <DanielK_WMDE_> aude: if you only have the ID from a db query, then yes.
22:19:01 <DanielK_WMDE_> but that's not what TitleValue is about
22:19:10 <TimStarling> when I say a foreign title, I mean a Title object with mInterwiki !== ''
22:19:14 <aude> site link = site id + page name
22:19:27 <TimStarling> they are traditionally used by the parser
22:19:40 <TimStarling> I mean, Title::secureAndSplit() is basically a parser outgrowth
22:20:28 <TimStarling> I'm just wondering if we really need foreign Title objects at all
22:20:34 <brion> so title components are traditionally (interwiki:)?(namespace:)?(text)(#hash)?
22:20:35 <DanielK_WMDE_> TimStarling: this could go into a TitleParser implementation. Though the TitleParser interface only defines parsing of *local* links.
22:20:39 <aude> i suppose the site links do store the full page title
22:20:42 <brion> where if there's an interwiki, we don't really fiddle with namespaces
22:20:47 <aude> e.g. Category:Berlin
22:20:53 <brion> it's funky but you can kinda think of an interwiki as an extended namespace :)
22:20:55 <TimStarling> or if we can use an object to represent foreign titles that is not derived from Title
22:21:42 <TimStarling> brion: yes
22:21:57 <TimStarling> that is basically a little fragment of the wikitext grammar, displaced from Parser to Title
22:22:00 <brion> i guess the ultimate question is "what do we need to slot in to the spaces that are normally local title objects"
22:22:08 <DanielK_WMDE_> TimStarling: in my mind, that would not really be a "title" (since we can#t normalize it), but rather a "link". but whatever :)
22:22:14 <aude> separating interwiki links from title seems good
22:22:21 <brion> hmm, i like that
22:22:23 <aude> keeping title simple, for local links
22:23:11 <brion> yes i can be convinced of that
22:23:22 <DanielK_WMDE_> i think we are getting a bit sidetracked with the interwiki stuff. TitleValue is about local links only. Let's worry about interwiki links another time.
22:23:30 <aude> +1
22:23:39 <brion> keep core title down to local (namespace,title) pair, which is something we pass around and store as a unit *all the time*
22:23:52 <brion> and leave interwikis and hashes to future link objects where they're actually needed
22:24:26 <MaxSem> i.e. in old Title for now?
22:24:33 <brion> MaxSem: yes
22:24:37 <DanielK_WMDE_> exactly
22:24:49 <DanielK_WMDE_> so, to get back on track: the main criticism seems to be "but then we need to pass around the pesky Parser/Formatter objects everywhere".
22:24:55 <brion> so that mostly leaves the parser/formatter and registry questions
22:25:05 <brion> easy answer: put them on IContext
22:25:12 <MaxSem> oh noes
22:25:14 <brion> which we already pass around everywhere ;)
22:25:15 <DanielK_WMDE_> i can only say to that "yes, but that's really a good thing, and not as annyoing as you might think".
22:25:26 <TimStarling> I think there was some concern on the mailing list about how much code will be touched by the Title -> TitleFormatter/TitleParser migration
22:25:33 <MaxSem> it'll grow to be the next god object that we'll need to slaughter
22:25:41 <DanielK_WMDE_> TimStarling: tons and tons, if we do everythign at once
22:25:45 <DanielK_WMDE_> but there's absolutely no need to
22:25:50 <^d> We never really needed IContext. We should've just kept $mediaWiki global ;-)
22:25:51 <DanielK_WMDE_> TitleValue and Title can easily co-exist
22:25:52 <brion> i think we should explicitly *not* do it all at once, yes
22:26:13 <brion> make sure it's easy to get a TitleValue from a Title and vice-versa
22:26:16 <DanielK_WMDE_> brion: so, tons of stuff depend on IContext. This means, to avoid a tangle, IContext should depend on as little as possible.
22:26:18 <TimStarling> we should at least have a sample though
22:26:20 <brion> and start building new interfaces on TitleValue
22:26:31 <TimStarling> so we know what we're getting ourselves in for
22:26:34 <brion> yeah
22:26:46 <brion> anyone have a module they'd like to volunteer for migration ? :)
22:26:55 <DanielK_WMDE_> brion: otherwise, you cet this: to construct X, you need an IContext. To construct an IContext, you need A, B, C, D, E, F, ..... Q, R...
22:27:15 <DanielK_WMDE_> sure, you could null/stub some out, but you then need to know in advance which parts of IContext X actually uses.
22:27:17 <DanielK_WMDE_> not nice
22:27:17 <qgil> #help anyone have a module they'd like to volunteer for migration ? :)
22:27:30 <TimStarling> DanielK_WMDE_: RequestContext is constructible with no arguments, isn't it?
22:27:52 <DanielK_WMDE_> TimStarling: well, the "arguments" are global state.
22:27:58 <TimStarling> it doesn't even have a __construct()
22:28:11 <TimStarling> it just uses mutators
22:28:12 <DanielK_WMDE_> which makes it worse: you have to know which global state to control or restore before constructing the context object
22:28:42 <MaxSem> the whole point of context that it *kill* global state
22:29:52 <DanielK_WMDE_> MaxSem: but what it currently does it *wrap* global state
22:29:55 <brion> so
22:29:56 <ori-l> $requestContext = &$GLOBALS; /* DON'T LOOK AT ME */
22:30:04 <DanielK_WMDE_> :P
22:30:13 <brion> imho the big win comes from separating the state/factory methods from the value object itself
22:30:34 <MaxSem> DanielK_WMDE_, that's only for main execution path, it doesn't have to
22:31:13 <TimStarling> brion: what do you think of my idea of having ServiceRegistry be a member of RequestContext?
22:31:29 <DanielK_WMDE_> MaxSem: yes. but it's hard to construct robust code for creating a "celan" RequestContext for e.g. testing.
22:31:42 <DanielK_WMDE_> and to do so, you'd have to create a ton of stuff you really don't need for your test.
22:31:47 <TimStarling> currently we have IContextSource, which can be implemented without much difficulty
22:31:55 <brion> TimStarling: that's probably what I'd do... otherwise we have a second global object we're passing around with some other method
22:32:01 <TimStarling> but if we have a hundred factory functions in it, it won't be so easy to implement
22:32:20 <DanielK_WMDE_> brion, TimStarling: the point of the registry thing is that it *doesn* get passed around. ever.
22:32:23 <TimStarling> but if you split out the hundred factory functions to their own class, it will still be possible to implement IContextSource from scratch
22:32:34 <brion> aho
22:32:37 * brion rereads
22:32:42 <DanielK_WMDE_> it's a small, isolated bit of state that gets used *only* in static entry points and is *never* a memebr of anything
22:32:46 <aude> DanielK_WMDE_: it'd be accessed statically?
22:32:52 <DanielK_WMDE_> nothing depends on it, so it's free to depend on the services it needs.
22:32:52 <aude> yeah....
22:33:09 <DanielK_WMDE_> yes, it would. it's only purpose it to provide static access to the service objects
22:33:26 <brion> so my concern with that is it puts us back to having global state that you can't change locally
22:34:27 <robla> (just to note: we're over halfway through, and still on the first RFC. that's probably fine, but if anyone was dying to get to the other RFCs, they should speak up)
22:34:28 <DanielK_WMDE_> brion: yes, but it's used in *very* limited locations. all the real logic would not need global state, and would also not need any factories, registries, contexts - it would ask exactly for the services it needs, and nothing more
22:34:31 <DanielK_WMDE_> that's the idea
22:34:34 <TimStarling> DanielK_WMDE_: except that we have thousands of static entry points, by the obvious definition
22:34:40 <DanielK_WMDE_> that makes these components reusable and testable
22:34:58 <TimStarling> we have thousands of static and global functions that access global state
22:35:10 <DanielK_WMDE_> TimStarling: sure, no need to deal with all of them. deal just with the ones that have a need for creating an object that requires such a service.
22:35:49 <TimStarling> I'm concerned that you may be designing an architecture which would work well from scratch, but not so well for the MW core
22:35:52 <DanielK_WMDE_> basically, we'd convert component X to use TitleValue, and require the mentioned service objects. Then we'd use the registry in the static entry points that create an insteanc of X.
22:35:57 <DanielK_WMDE_> then we look at Y. and so on
22:36:05 <DanielK_WMDE_> no need for a hige migration or refactoring
22:36:49 <TimStarling> alright, so to wrap up for now...
22:36:57 <qgil> TimStarling, wait
22:37:00 <brion> so... my recommendation would be to prototype converting some stuff (limited area) and we can revisit this with some more experience
22:37:06 <qgil> please use #info in your summaries
22:37:07 <MaxSem> DanielK_WMDE_, that'll result in half of components requiring Title, another one - TitleValue
22:37:12 <TimStarling> brion: I was about to say that
22:37:12 <DanielK_WMDE_> TimStarling: the migration part is basically to push the need for accessing the static registry up the stack, towards the "edges" of the program, until, ideally, it's only done during initial bootstrapping.
22:37:20 <MaxSem> it'll be hard to glue them together
22:37:23 <DanielK_WMDE_> MaxSem: yes, that's exactly the idea.
22:37:30 <DanielK_WMDE_> no, why?
22:37:35 <TimStarling> if DanielK_WMDE_ can make a prototype without us agreeing to merge it, that would be a good outcome
22:37:35 <DanielK_WMDE_> it's easy to construct one from the other
22:37:41 <brion> MaxSem: not hard, just slightly ugly $title->asTitleValue() etc
22:37:49 <TimStarling> then we can evaluate it at that point
22:37:50 <brion> data conversion \o/
22:37:59 <DanielK_WMDE_> brion: indeed
22:38:30 <DanielK_WMDE_> TimStarling: i'd be willing to prototype this on a small module. say, a simple special page or api module
22:38:41 <TimStarling> ok
22:38:51 <TimStarling> I think that will help to focus discussions somewhat
22:38:56 <DanielK_WMDE_> (these however are bad examples, because it's hard to control their instantiation, and constructor parameters are fixed)
22:38:56 <qgil> #action by TimStarling: if DanielK_WMDE_ can make a prototype without us agreeing to merge it, that would be a good outcome. Then we can evaluate it at that point
22:39:11 <TimStarling> special pages are not so bad for constructor parameters etc.
22:39:25 <TimStarling> I was looking at their current implementations, they really don't have much global state anymore
22:39:26 <qgil> #info <DanielK_WMDE_> TimStarling: i'd be willing to prototype this on a small module. say, a simple special page or api module
22:39:50 <qgil> anything else about this topic before we move to the next?
22:40:07 <DanielK_WMDE_> brion, TimStarling: i gather that there's agreement on trying to use TitleValue instead of Title where possible, but concern about how to access the serives objects for parsing and formatting. the two options being a) IContext and b) a separate static registry that is not passed around.
22:40:19 <brion> *nod*
22:40:20 <qgil> Anything anybody wants to say about this topic with info"before we move on?
22:40:42 <qgil> #info <DanielK_WMDE_> brion, TimStarling: i gather that there's agreement on trying to use TitleValue instead of Title where possible, but concern about how to access the serives objects for parsing and formatting. the two options being a) IContext and b) a separate static registry that is not passed around.
22:40:43 <DanielK_WMDE_> qgil: what i just said
22:40:48 <qgil>Â :)
22:40:49 <DanielK_WMDE_> exactly :)
22:41:09 <qgil> TimStarling, do you want to sttart a new topic?
22:41:14 <TimStarling> DanielK_WMDE_: I think that is fair
22:41:29 <TimStarling> do we have any other RFCs for which the proposer is present and interested in discussing it?
22:41:40 <qgil> Any official agreement about this point for the notes?
22:41:42 <DanielK_WMDE_> TimStarling: i'll request a week's coding time to work on this.
22:41:54 <aude>Â :)
22:41:56 <qgil> #info <DanielK_WMDE_> TimStarling: i'll request a week's coding time to work on this.
22:42:16 <MaxSem> ^d, configuration database?
22:42:17 <qgil> ok, new topic?
22:42:34 <^d> MaxSem: Tim said "and interested in discussing"Â ;-)
22:42:38 <MaxSem> lol
22:42:52 * robla orders Chad to be interested in configuration database  :-P
22:43:02 <brion> i'd love to discuss the styling in templates but i'd want jon here for that
22:48:21 <AaronSchulz> TimStarling: this would be a cause for avoiding utility classes in some cases more so
22:48:26 <^d> Something fancier for wiki farms.
22:48:39 <AaronSchulz> otherwise you get stuck passing Config into every little method
22:48:43 <DanielK_WMDE_> just start using it for some stuff. config can still be done in the old style, but could be overwritten by setting o nthe wiki, for some settings that are defined for this
22:50:07 <legoktm> I'd be willing to work on some of it
22:50:24 <legoktm> DanielK_WMDE_: There could be something like wgConf's extractAllGlobals()
22:50:29 <^d> That ^
22:50:31 <TimStarling> legoktm: maybe you should file your own RFC about it
22:50:41 <TimStarling> I think we could have competing RFCs
22:50:49 <DanielK_WMDE_> ^d: sure - that's what i suggested. have an new/extra system with for accessing config, and use that to override "traditional" settings. fall back on the old stuff.
22:50:59 <AaronSchulz> TimStarling: the one that sits there and the one that doesn't
22:50:59 <qgil> #info <TimStarling> anyway, we are mostly dreaming if we don't have anyone to drive this
22:51:02 <OwynD> we still have LocalSettings, DefaultSettings etc.
22:51:07 <qgil> #info <legoktm> I'd be willing to work on some of it
22:51:17 <legoktm> TimStarling: Ok, I'll try and find some time for it
22:51:23 <OwynD> our local settings has a call to that factory stuff at the right place to set all the custom vars for a wiki
22:51:38 <TimStarling> can we talk about password requirements?
22:51:48 <AaronSchulz> csteipp: [cough]
22:51:48 <qgil> #info <OwynD> we have an extension called WikiFactory that basically does this for us.
22:51:50 <^d> Anyway, the only last thing I'll say on the subject is this: it doesn't need to be an OMGREWRITE like I advocated forever.
22:52:00 <^d> It can be fixed incrementally.
22:52:09 <^d> SiteConfiguration is a good enough starting point we can iterate from.
22:52:12 <qgil> TimStarling, can you please summarize any resolution about the current topic, please?
22:52:17 <csteipp> Password requirements? I'm all for it.
22:52:22 <^d> (Trying to do OMGEVERYTHING sets this project up for failure)
22:52:23 <^d> </done>
22:52:28 <brion> OwynD: can that be used to switch full configuration at runtime? I used a similar trick in StatusNet a few years ago to switch configs in background daemons
22:52:43 <brion> though that had fewer globals so was easier :D
22:53:09 <TimStarling> qgil: current RFC probably abandoned, legoktm to file new RFC
22:53:15 <OwynD> yep, i feel like that part is a bit "sketchy" but it does work.
22:53:23 <qgil> #info <TimStarling> qgil: current RFC probably abandoned, legoktm to file new RFC
22:53:28 <OwynD> for example we have to launch a maintenance script in a wiki context.
22:53:35 <DanielK_WMDE_> ^d: nicely put :)
22:53:39 <OwynD> so it has all the right variables defined.
22:54:02 <OwynD> one of our developers wrote a wrapper for that which just resets the vars without restarting the maintenance script over again, and it does work.
22:54:04 <brion> OwynD: nice, i'll make a note to follow up on that for later :)
22:55:52 <TimStarling> various people are talking about character set requirements, but I'm not sure if that is actually proposed
22:56:08 <TimStarling> but if someone submitted that to gerrit, I would probably approve it
22:56:16 <TimStarling> since some admins like character set requirements
22:56:55 <csteipp> Only length was in the proposal, but expiration and charset could also be in there. Also, different people having a different policy (the second part of the rfc)
22:57:00 <qgil> #info <TimStarling> there are a couple of really simple features proposed here. One is to make it so that increasing $wgMinimalPasswordLength doesn't break everything. Fine, hardly even needs an RFC.
22:57:03 <brion> ok so do we just have the character limit setting, or are we also including password complexity requirements for groups?
22:57:44 <MaxSem> I fucking hate mandatory "you must have at least one number and one uppercase char". though my passwords tend to comply:P
22:57:48 * qgil wonders whather you want/need a hard stop at o'clock, in 3 minutes.
22:57:50 <bawolff> +1
22:57:55 <TimStarling> yeah, password requirements for groups is not so simple
22:58:00 <TimStarling> but commonly requested
22:58:14 <TimStarling> I think there is a bug or changeset for it?
22:58:24 <csteipp> There is at least a bug for it
22:58:28 <qgil> #info <csteipp> Only length was in the proposal, but expiration and charset could also be in there. Also, different people having a different policy (the second part of the rfc)
22:58:42 <csteipp> I think Tyler took it out of the password api patch
22:58:44 * DanielK_WMDE_ 's password is knapsack. it's np hard.
22:58:48 <TimStarling> you would need to ask new admins to change their password on their first login after promotion
22:59:02 <siebrand> +1 for sticking to time boxes, qgil
22:59:22 <TimStarling> which is pretty simple once you have expiry and forced reset features
22:59:29 <csteipp> TimStarling: That gets easier if my password expiration gets in. If we see out of policy password, we expire their password, and they have X days to change it before they're force to reset it.
22:59:30 <DanielK_WMDE_> TimStarling: basically, if *any* user tried to log in, and the password matches but doesn't meet the requirements (for that user), make them set a new one.
22:59:35 <DanielK_WMDE_> should be simple
22:59:42 <TimStarling> you know the forced reset feature we need as a replacement for the hash leak response hack
23:00:00 * aude already was forced to reset my wikidata password
23:00:01 <ori-l> yes, i was just going to say
23:00:04 <ori-l> there's quite a lot of overlap
23:00:13 <brion> excellent
23:00:22 <brion> so that sounds feasible and not undesirable?
23:00:35 <TimStarling> so, what I would like from this RFC is for the discussion to be moved out to the talk page
23:00:52 <qgil> #info <TimStarling> so, what I would like from this RFC is for the discussion to be moved out to the talk page
23:01:24 <qgil> Is this the end of the meeting?
23:01:35 <TimStarling> almost
23:01:45 <qgil> anything else?
23:01:47 * aude yawns
23:01:50 <TimStarling> also, we would like expiration and forced reset to be part of the RFC
23:02:15 <TimStarling> since the code overlaps with the group requirements feature
23:02:47 <csteipp> Yep. I'll talk with Matt about adding that in. One of us can do that, I'm sure.
23:02:59 <TimStarling> I think once the document is cleaned up, we can just accept it
23:03:07 <TimStarling> since the mediawiki feature is pretty uncontroversial
23:03:08 <qgil> #action Password requirements: <TimStarling> what I would like from this RFC is for the discussion to be moved out to the talk page. Also, we would like expiration and forced reset to be part of the RFC
23:03:15 <TimStarling> the controversial part of this is the WMF configuration
