My name is Mayank Jindal. I am third year undergraduate student
currently studying at Indian Institute of Technology, Kharagpur. I want to
take part in Gsoc-2017 from Wikimedia.
I have knowledge of C, C++, JAVA, Python, Android app development and Web
development and beginner in *Machine Learning, Artificial Intelligence.*
I am very enthusiastic to learn new skills which would be required.
Kindly guide me to proceed further.
Third year undergraduate student,
Indian Institute of Technology Kharagpur
Mobile : +91- 7076670299 || 8875432718
Hi, this is a request from the organizers of the Wikimedia Developer Summit
2016 (San Francisco, January 9-11).
We are looking for candidates to become main topics of the next Summit.
Ideally complex topics with a high user impact (direct or indirect) and
ramifications in multiple technical areas. Deciding a few main topics
beforehand will help us inviting the people needing to be involved,
especially non-WMF contributors requiring travel sponsorship.
We are also looking for volunteers who want to get involved in the
organization of the Summit, or want to provide feedback to improve our
If you have proposals for main topics and/or want to volunteer, please
Context: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2017 &
Engineering Community Manager @ Wikimedia Foundation
We’ve been busy working on building a replacement for RCStream. This new
service would expose recentchanges as a stream as usual, but also other
types of event streams that we can make public.
But we’re having a bit of an existential crisis! We had originally chosen
to implement this using an up to date socket.io server, as RCStream also
uses socket.io. We’re mostly finished with this, but now we are taking a
step back and wondering if socket.io/websockets are the best technology to
use to expose stream data these days.
The alternative is to just use ‘streaming’ HTTP chunked transfer encoding.
That is, the client makes a HTTP request for a stream, and the server
declares that it will be sending back data indefinitely in the response
body. Clients just read (and parse) events out of the HTTP response body.
There is some event tooling built on top of this (namely SSE /
EventSource), but the basic idea is a never ending streamed HTTP response
So, I’m reaching out to to gather some input to help inform a decision.
What will be easier for you users of RCStream in the future? Would you
prefer to keep using socket.io (newer version), or would you prefer to work
directly with HTTP? There seem to be good clients for socket.io and for
SSE/EventSource in many languages.
https://phabricator.wikimedia.org/T130651 has more context, but don’t worry
about reading it; it is getting a little long. Feel free to chime in there
or on this thread.
Your help is welcome to provide feedback and guidance:
== in "mediawiki/tools/mwdumper": ==
Thanks in advance for your reviews.
Of last weeks' 5 listed patches, 4 got merged & 1 got reviewed. Thanks
to Amire80, Daniel, FlorianSW, Jdlrobson, MatmaRex, Smalyshev, Tjones!
Andre Klapper | Wikimedia Bugwrangler