I think we should look at how our users are using the API? Is there a way to get a dump of the moment common requests? It would be great to separate these out into 3rd party usage and Wikimedia usage.
In terms of sensible defaults - what queries can we simplify? Personally I think the more data we return in a response the better. We should be minimising the number of HTTP requests. I think how people use it is the best way to learn and improve. On Tue, Jul 29, 2014 at 1:40 PM, Max Semenik <[email protected]> wrote: > Thanks, Brion! > > On Tue, Jul 29, 2014 at 10:32 AM, Brion Vibber <[email protected]> > wrote: >> >> On a slow connection pulling down multiple sections in one blob is tricky >> -- JSON decoders don't normally stream so we end up being pretty slow with >> that "second section and beyond" request. > > You still can request separate sections. > > >> >> I would love to be able to include action=query stuff along with a mobile >> view request, such as grabbing the current user and site metadata. > > Sigh, without core support we can only do one-offs to return select parts in > mobileview. Is there anything particular that you want? Also, it's not a > browser environment and you can actually make a couple reqests in parallel > to e.g. decouple siteinfo retrieval. > > >> >> Handling reference popups is dependent on loading the refs section, which >> appears somewhere near the end. See above about slow connections. Could we >> preextract them and ship them with the first section as metadata? > > Already possible: §ions=0|references > > >> >> There are some oddities with remote file pages not returning a mod >> timestamp. > > That's an interesting problem: the wiki itself doesn't know if a remote > repository page has changed, so we have either to not cache the information > about such pages (will be slow) or expect this information to be outdated. > > >> >> Exposing CSS and scripting modules for extensions used would be nice. >> Alternately we can try to retool things intoself contained embeddable I >> frames. > > This is something worth investigating (as well as returning mw.config values > related to page being retrieved), however I suspect that there will be a few > wwonderful obstacles to work around, as a lot of extensions just add their > modules/variables to OutpuPage in hooks scarily close to page display, > making a lot of assumptions that are not true for API page views. > > > > -- > Best regards, > Max Semenik ([[User:MaxSem]]) > > > _______________________________________________ > Mobile-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/mobile-l > -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon _______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
