spelling correction: * the most /common/ requests
On Tue, Jul 29, 2014 at 2:48 PM, Jon Robson <[email protected]> wrote: > 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 -- 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
