Native JSON loading (was: system module loader)
What about native JSON loading?
How would this be different from XHR + JSON.parse() sugar?
Are you proposing loading the JSON from the server as though it were a module?
FWIW, most of my JSON-loading use cases are post-page-load, they are of the "fetch some data from the server based on user input" variety.
In a very very very small number of cases (session state mostly) I also will load data at the same time as page load; for these cases I currently use SCRIPT tags and code ~ like this on the server
print("Content-type: application/x-javascript\n") /* do stuff */ print "var o = " + uneval(o);
I’d like this idea, especially when native JSON loading is combined with JSONPath (if possibly provided by standard goessner.net/articles/JsonPath ), e.g. I have a large JSON formatted content served by server: Content-Type: application/json { brief: { // 10 properties }, /* This is a stop-point */ // other 100+ properties, over 2MB in size } Once native JSON loading is suppoted, when I load a uri with JSONPath such as ./api/info.json#brief, would it be possible that user agent streamed this response, read until the close of brief property (The stop-point in code example), then close this connection (or other ways to notify server that remaining content is not required), this would (in some case) be benefit for network performance.
Gray Zhang Mail: otakustay at gmail.com Blog: www.otakustay.com Weibo: www.weibo.com/otakustay
From: Wes Garland Sent: Friday, March 09, 2012 1:42 AM To: David Bruant Cc: es-discuss Subject: Re: Native JSON loading (was: system module loader)
What about native JSON loading?
How would this be different from XHR + JSON.parse() sugar?
Are you proposing loading the JSON from the server as though it were a module?
FWIW, most of my JSON-loading use cases are post-page-load, they are of the "fetch some data from the server based on user input" variety.
In a very very very small number of cases (session state mostly) I also will load data at the same time as page load; for these cases I currently use SCRIPT tags and code ~ like this on the server
print("Content-type: application/x-javascript\n") /* do stuff */ print "var o = " + uneval(o);
Le 08/03/2012 18:27, Mike Samuel a écrit :
I've been using node.js for a couple of month and in node, you can do
The JSON file is parsed automatically. This is very handy for configuration files. I think the heuristic they use to detect a JSON file is the ".json" suffix. For the web, the content-type would be a far better candidate :-)
Besides node.js, jQuery also has facilities that parse JSON files and return an object when the data retrieved from the server has been served with application/json.
What about native JSON loading?
Le 08/03/2012 18:27, Mike Samuel a écrit : > http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders mentions > a system module loader. > > Has the behavior of the system module loader been speced at all? > > If not, would it be worthwhile specifying that when it loads an http > or https URL, it does so with a fairly minimal Accept header that > excludes non-script mime-types, especially text/html and */*: > > Accept: application/javascript;version=next, application/javascript > > or whichever is the preferred mime-type. I've been using node.js for a couple of month and in node, you can do var o = require('myData.json') The JSON file is parsed automatically. This is very handy for configuration files. I think the heuristic they use to detect a JSON file is the ".json" suffix. For the web, the content-type would be a far better candidate :-) Besides node.js, jQuery also has facilities that parse JSON files and return an object when the data retrieved from the server has been served with application/json. What about native JSON loading? David