Bernd, Dmitry, and I met with Gabriel and Marko from the services team. Notes:
* Bernd to use https://github.com/wikimedia/service-template-node as a starting point * Gabriel, Marko to look into cache invalidation / freshness stuff. Usually, for the mobile apps the latest non-stale response is what's wanted by the client. * Apps team should engage with services on getting the mapping and other fronting service requirements for rest.wikimedia.org deployed. * The first target service is for something akin to what would be required by a "Wikipedia Lite" experience, similar in terms of data transformation to OCG, Kiwix, Text Extracts.
-Adam
Thanks for the update! Just a couple questions/comments:
On Tue, Feb 24, 2015 at 2:17 PM, Adam Baso abaso@wikimedia.org wrote:
Bernd, Dmitry, and I met with Gabriel and Marko from the services team. Notes:
- Bernd to use https://github.com/wikimedia/service-template-node as a
starting point
- Gabriel, Marko to look into cache invalidation / freshness stuff.
Usually, for the mobile apps the latest non-stale response is what's wanted by the client.
I'd also like to add an "if-modified-since" support, so we can send GET requests but only have data sent back over the wire if it's newer than Revision X or some etag has expired, etc.
- Apps team should engage with services on getting the mapping and other
fronting service requirements for rest.wikimedia.org deployed.
- The first target service is for something akin to what would be required
by a "Wikipedia Lite" experience, similar in terms of data transformation to OCG, Kiwix, Text Extracts.
Why aren't we doing something to solve a problem w/ the current apps? For example, aggregating image info and article info together into one response?
-Adam
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I'd also like to add an "if-modified-since" support, so we can send GET requests but only have data sent back over the wire if it's newer than Revision X or some etag has expired, etc.
Agreed.
Why aren't we doing something to solve a problem w/ the current apps? For example, aggregating image info and article info together into one response?
If I'm not mistaken, the thought is that if this relatively simpler service experiment goes well, then it will make sense to go ahead with pursuit of the bigger composite service (and probably a suite of services in due time).
If I'm not mistaken, the thought is that if this relatively simpler service experiment goes well, then it will make sense to go ahead with pursuit of the bigger composite service (and probably a suite of services in due time).
Right, so we both agree we should start simplest—I just forgot the initial scope of this task:
Scope: the service takes an article name, and serves article content in a
text-only format (but including wikilinks and external links).
IOW: just learning about node, not necessarily building something we'll use in production.
On Tue, Feb 24, 2015 at 2:56 PM, Adam Baso abaso@wikimedia.org wrote:
I'd also like to add an "if-modified-since" support, so we can send GET
requests but only have data sent back over the wire if it's newer than Revision X or some etag has expired, etc.
Agreed.
Why aren't we doing something to solve a problem w/ the current apps? For example, aggregating image info and article info together into one response?
If I'm not mistaken, the thought is that if this relatively simpler service experiment goes well, then it will make sense to go ahead with pursuit of the bigger composite service (and probably a suite of services in due time).
Thanks for the summary, Adam!
On Tue, Feb 24, 2015 at 11:53 AM, Brian Gerstle bgerstle@wikimedia.org
- Gabriel, Marko to look into cache invalidation / freshness stuff.
Usually, for the mobile apps the latest non-stale response is what's wanted by the client.
I'd also like to add an "if-modified-since" support, so we can send GET requests but only have data sent back over the wire if it's newer than Revision X or some etag has expired, etc.
Yes, this is something we should support. We already set a versioned ETag, but don't validate If-Match requests yet. Should be easy to add. Tracked in https://phabricator.wikimedia.org/T90633.
- Apps team should engage with services on getting the mapping and other
fronting service requirements for rest.wikimedia.org deployed.
- The first target service is for something akin to what would be
required by a "Wikipedia Lite" experience, similar in terms of data transformation to OCG, Kiwix, Text Extracts.
Some pointers for content massaging:
- https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec - mwoffliner https://github.com/wikimedia/mediawiki-extensions-Collection-OfflineContentGenerator-zim_renderer/blob/6d204c7943efa2a7d03e59f988bd6ffc2903c914/lib/mwoffliner.js (part of OCG) - kiwix mwhtmldumper https://github.com/adamwight/kiwix-other/blob/b87e80631d795fa93d3374973709d8f1cee601d4/mwhtmldumper/mwhtmldumper.js
Gabriel
Adam: Thank you for the summary. Gabriel/Marko: Thank you for the session earlier, the links, and esp. the service template which are very helpful to get started.
+1 for taking If-None-Match headers into account to help clients downloading duplicate payloads. This should be useful in the future.
Cheers, Bernd