Wikimedia Bugzilla is closed!

11:54 < anomie> legoktm, ebernhardson: ... This would be a lot easier if action=flow could just always use a 
                token, instead of using one sometimes and sometimes not.
11:54 < Reedy> read modules are usually action=query submodules
11:56 < legoktm> making it an action=query module would be a nice thing, but the read and write modules shared 
                 a lot of common code and I couldn't really think of a good way to make that work without just 
                 having them be one large submodule
11:57 < legoktm> also, when I first started writing it, action=flow was just write stuff, and then we added 
                 some read modules to it
12:03 < anomie> legoktm, ebernhardson: Hmm. So it probably doesn't make a whole lot of sense to have the flow 
                read actions being a query submodule, since action=query&meta=flow&flowsubmodule=... is kind 
                of silly when we could do action=flowquery. If you want to keep them all in action=flow, it 
                would basically mean reimplementing the core token handling because core doesn't have a way to 
                conditionally have action=flow take a token.
12:07 < anomie> ebernhardson: With a little trickery you can have the ApiFlow implement both action=flow and 
                action=flowquery: just check $action in the constructor to set the return value of 
                needsToken() (false or 'csrf') and use the appropriate list of submodules. Then everything 
                about needsToken can be removed from ApiFlowBase and all the token checking can be removed 
                from ApiFlow::execute().