Hey James,

You touch on some interesting points in your email.

I don't think initial page load time is a big issue, since the query results get cached anyway. Obtaining them asynchronously after page load would just make it slower. However I think we can improve a lot on the current architecture of many result printers, especially those with filter and continuation options. For one, they should just load the data in the page, and have a separate JS file that holds the actual logic code, which only gets run _after_ page load, which would prevent it from slowing down initial page rendering. Another thing is that there currently is no nice way to get more data after page load, forcing formats with filters to load all data they might need to display, while a lot of it might not be needed in most cases. Having something for this would also allow query printers suhc as lists and tables to live add more results, instead of having a further results link which takes you to Special:ask, which is not that nice.

I have a bunch of ideas on how this could be implemented nicely (somewhat explained in this lightning talk [0]), but have no time right now to really poke at it. Maybe as part of rewriting the Exhbit stuff [1] or creating something equivalent would be a time to also push this. One thing I already did going a bit in this direction is creating an ask API, which is still in alpha, but will be in 1.7 (as alpha functionality).

[0] https://www.youtube.com/watch?v=XQfXCJzac30 - http://ext.bn2vs.com/smwcon/spark/
[1] http://semantic-mediawiki.org/wiki/Exhibit_rewrite_funding


Jeroen De Dauw
Don't panic. Don't be evil.