[Wikitech-l] JSON and Scribunto
There's a long-standing request for Scribunto to provide library functions for JSON encoding and decoding. The advantage of this would be improved interoperability with the growing number of extensions that use JSON (e.g. JsonConfig, Graph). The disadvantages include: * People may store data in JSON blobs that must be parsed where a module using mw.loadData would be more appropriate. * People may write templates that attempt to bypass the normal MediaWiki parameter handling mechanism in favor of passing a JSON blob, which would likely lead to page wikitext that is harder for end users to understand. So, let's discuss it: do the advantages outweigh the potential disadvantages? Are there additional advantages or disadvantages not yet mentioned? -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JSON and Scribunto
Disclaimer, Obviously as the developer of JsonConfig Graph, I am strongly in favor of Json capabilities in Lua. That being said, would the new Lua functions be any more in danger of misuse than the powerful raw HTML generation library, or the capability of pulling content of may pages in a list (both of which are already available in Lua), e.g. for page in list_of_pages: mw.getContent(page) I feel that most powerful functions could be abused, and at the end of the day, there is no such thing as a perfect idiot-proof way, simply because there are a lot of brilliant idiots. So instead of prohibiting a function that is clearly demanded by many developers, let us implement it and rely on 1) performance tuning once we see a problem, 2) usage/code reviewing, 3) documenting recommended usage patterns. On Tue, Nov 4, 2014 at 3:45 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: There's a long-standing request for Scribunto to provide library functions for JSON encoding and decoding. The advantage of this would be improved interoperability with the growing number of extensions that use JSON (e.g. JsonConfig, Graph). The disadvantages include: * People may store data in JSON blobs that must be parsed where a module using mw.loadData would be more appropriate. * People may write templates that attempt to bypass the normal MediaWiki parameter handling mechanism in favor of passing a JSON blob, which would likely lead to page wikitext that is harder for end users to understand. So, let's discuss it: do the advantages outweigh the potential disadvantages? Are there additional advantages or disadvantages not yet mentioned? -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JSON and Scribunto
I think we should do it. The disadvantages aren't really disadvantages, since users could just write their own JSON-processing module if we don't give them one, and then those could both be issues anyway. Jackmcbarn On Tue, Nov 4, 2014 at 3:45 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: There's a long-standing request for Scribunto to provide library functions for JSON encoding and decoding. The advantage of this would be improved interoperability with the growing number of extensions that use JSON (e.g. JsonConfig, Graph). The disadvantages include: * People may store data in JSON blobs that must be parsed where a module using mw.loadData would be more appropriate. * People may write templates that attempt to bypass the normal MediaWiki parameter handling mechanism in favor of passing a JSON blob, which would likely lead to page wikitext that is harder for end users to understand. So, let's discuss it: do the advantages outweigh the potential disadvantages? Are there additional advantages or disadvantages not yet mentioned? -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JSON and Scribunto
On Tue, Nov 4, 2014 at 1:02 PM, Yuri Astrakhan yastrak...@wikimedia.org wrote: On Tue, Nov 4, 2014 at 3:45 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: There's a long-standing request for Scribunto to provide library functions for JSON encoding and decoding. [Advantages: lots of use case, Disadvantages: potential for abuse] I feel that most powerful functions could be abused, and at the end of the day, there is no such thing as a perfect idiot-proof way, simply because there are a lot of brilliant idiots. So instead of prohibiting a function that is clearly demanded by many developers, let us implement it and rely on 1) performance tuning once we see a problem, 2) usage/code reviewing, 3) documenting recommended usage patterns. Fully agreed. The nice thing about JSON in particular is that it's a reasonably simple and constrained format, and thus lends itself well to optimization if its usage becomes widespread enough to support it. We have a general issue of coming up with better ways of promoting efficient coding practices in Lua, but that problem is independent of whether we add JSON support. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JSON and Scribunto
On 4 November 2014 20:45, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: * People may store data in JSON blobs that must be parsed where a module using mw.loadData would be more appropriate. * People may write templates that attempt to bypass the normal MediaWiki parameter handling mechanism in favor of passing a JSON blob, which would likely lead to page wikitext that is harder for end users to understand. If people want a function they will write something that will do it. Remember how ParserFunctions got an if statement? It was after excessively creative users had cobbled together one from whatever absolutely hideous hacks they could. So if you know there's a demand for this, I strongly suggest thinking hard and supplying a good implementation, else it is certain the users will come up with a hideous one. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
