All,
Thanks for the great responses. It seems like, Andrew, Ed, DataSift, and Mitar are now all offering overlapping solutions to the real-time diff monitoring problem. The one thing I take away from that is that if the API is robust enough to serve these 4 clients in real time, then adding another is a drop in the bucket.

However, as others like Yuvi pointed out, and Aaron has prototyped we could make this better, by serving an augmented RCstream. I wonder how easy it would be to allow community development on that project since it seems that it would require access to the full databases, which only WMF developers seem to have access to at the moment.

Make a great day,
Max Klein ‽ http://notconfusing.com/

On Mon, Dec 15, 2014 at 5:09 AM, Flöck, Fabian <Fabian.Floeck@gesis.org> wrote:
If anyone is interested in a faster processing of revision differences, you could also adapt the strategy we implemented for wikiwho [1], which is keeping track of bigger unchanged text chunks with hashes and just diffing the remaining text (usually a relatively small part oft the article). We specifically introduced that technique because diffing all the text was too expensive. And in principle, it can produce the same output, although we currently use it for authorship detection, which is a slightly different task.  Anyway, it is on average >100 times faster than pure "traditional" diffing. Maybe that is useful for someone. Code is available at github [2].

[1] http://f-squared.org/wikiwho 


On 14.12.2014, at 07:23, Jeremy Baron <jeremy@tuxmachine.com> wrote:

On Dec 13, 2014 12:33 PM, "Aaron Halfaker" <ahalfaker@wikimedia.org> wrote:
> 1. It turns out that generating diffs is computationally complex, so generating them in real time is slow and lame.  I'm working to generate all diffs historically using Hadoop and then have a live system listening to recent changes to keep the data up-to-date[2].

IIRC Mako does that in ~4 hours (maybe outdated and takes longer now) for all enwiki diffs for all time. (don't remember if this is namespace limited) But also using an extraordinary amount of RAM. i.e. hundreds of GB

AIUI, there's no dynamic memory allocation. revisions are loaded into fixed-size buffers larger than the largest revision.

https://github.com/makoshark/wikiq

-Jeremy

_______________________________________________
Wiki-research-l mailing list
Wiki-research-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l




Cheers, 
Fabian

--
Fabian Flöck
Research Associate
Computational Social Science department @GESIS
Unter Sachsenhausen 6-8, 50667 Cologne, Germany
Tel: + 49 (0) 221-47694-208
fabian.floeck@gesis.org
 
www.gesis.org
www.facebook.com/gesis.org






_______________________________________________
Wiki-research-l mailing list
Wiki-research-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l