https://bugzilla.wikimedia.org/show_bug.cgi?id=55727
--- Comment #2 from Nathan Larson <[email protected]> --- What I was hoping to do was make it so that applications could pull both page creations (rctype=new) and page deletions/restorations (rctype=log&rcaction=delete|restore) in one API pull rather than having to do two separate pulls (one to list=logevents and the other to list=recentchanges). The idea would be to reduce server load, since there could end up being a lot of these pulls, depending on how widely the extension that does the pulls gets used. Specifically, this is for the rewrite of the RPED extension (to be renamed InterwikiExistence), which will use periodic API pulls to keep the local list of existent Wikipedia pages mostly in sync with Wikipedia's. That way, it will be possible to have existence detection (i.e. red/blue interwiki links) for interwiki links such as [[wikipedia:Foo]]. This is sort of like bug 11, but it would be used on wikis that, being outside of the WMF farm, can't use the WMF backend and therefore have to rely on the API. The code for the API pulling is similar to what you see in the InterwikiMap extension, except the API pulling would probably need to be more frequent to keep the data reasonably up-to-date, since page creations, deletions and restorations occur more frequently than changes to the interwiki table. So my question would be, is it more efficient to implement this raction capability and thereby cut down on API pulls, or would it not be worth the expense in terms of database load? The other option is to have a bot get the data from the recentchanges IRC feed, but not all wikis are able to run a bot 24/7. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
