HomePhabricator

Refactor RCFeed configuration (backwards compatible)

Authored by Krinkle on Jan 6 2017, 1:27 AM.

Description

Refactor RCFeed configuration (backwards compatible)

Previously:

  • Engines had to be registered in $wgRCEngines.
  • The RCFeedEngine classes took no constructor arguments and were expected to send whatever text is previously formatted without any information about it. This generic design was flexible in allowing one to use any formatter with any engine with minimal configuration and no need for additional classes.
  • Each feed configured their destination by setting a 'uri' option that encodes the name of the engine in PHP as the uri scheme. Other uri components had to be used for any other parameters to the engine (host, port, path). While fairly limited, it was sufficient for the default engines in core.

Changes:

  • Allow feed classes to be directly associated with a feed in $wgRCFeeds via a new 'class' option - without the indirection of 'uri' and $wgRCEngines. All options are passed to the given class constructor. This matches the design used elsewhere in MediaWiki. (ObjectCache, FileRepo, FileBackend, JobQueue, LBFactory, etc.)

    This means we no longer enforce a 1:1 mapping of internet protocols to a specific feed engine, and it allows settings to be passed without being encoded as a URI neccecarily.

    Main use case for this refactor is EventBus (see I7edc4d57fa),

    Interestingly, this matches the (then incorrect) documentation written for $wgRCFeeds in 2961884b43 (which mentions an 'engine' property that would do the same thing).
  • Move the default 'omit' filters and unrestricted 'formatter' handling to a new FormattedRCFeed class, which remains the default.
  • Deprecate RecentChange::getEngine() in favour of RCFeed::factory().

Change-Id: I8be497c623c5d928762e3d3406a388f4d91add9a

Details