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.