On 03/10/2013 07:34 PM, Petr Bena wrote:
I appreciate someone does something, but this should
have been more
discussed.
Well, we can discuss this now. I don't like the discussions which end
up with "here's a design of our superpony which should have those 9000+
features", and then we have no progress. I think it's sort of nice we
have a starting point now.
I would like to highlight that our goal should NOT be
to do
this a way that is most simple for developers of mediawiki to
implement and most simple for devops to maintain and setup. Our goal
should be to make this feed most simple to implement into target
application (bot, tool) for the developers of that tool.
There are different type of clients, and they all have their own
"easiest format". WebSockets is pretty much the only serious option
there, and hence this is something which we really want to support.
WebSocket protocol is also very complex, so for non-browser apps I added
the second protocol (I am still not sure how good this idea is).
The ideal
feed should be pretty simple to be parseable by something as trivial
as a shell script with netcat or telnet on remote server (absolutely
no need to use some 3rd party libraries). I am fine with using JSON as
one option, but if it's the only option this new feed is supposed to
provide, it will be very hard to implement in some tools.
We want this to be a machine-readable feed. The two most widespread
universal formats for transferring machine-readable structure data are
XML and JSON. JSON parsing is almost always easier than XML (if it's
not, then it's probably the fault of the JSON library in use).
The text-based protocol works with netcat (that's how I tested it).
However, it turns out that awk and sed are not well-suited for parsing
structured data (have you ever tried to parse XML from a shell script?).
Basically
anything what will require some extra libraries will make it harder
than it actually is - despite it could be more flexible and faster.
I don't think I buy into the statement that lack of built-in JSON parser
is an issue with JSON, and not with that language's library structure.
-- Victor.