Essentially we want to be able to do things such as:
* Special case summaries for pages such as disambiguation/ potentially list pages 
* Move logic that bolds the title from client side js to the service
* Improve html summaries to ensure they are well formed html
* Move/add logic that strips parentheses 

Ultimately the goal is to make page previews dumb and the service smarter.

On Fri, 23 Jun 2017, 08:59 Bernd Sitzmann, <bernd@wikimedia.org> wrote:
+ Reading Infrastructure

I believe the summary endpoint is implemented directly in RB for now since it is a relatively simple mapping of TextExtracts. There is a yaml file and a JS file for this in RB. 
Even in the implementation moves to MCS there still would have to be a mapping in RB to expose the endpoint publicly, to store and retrieve saved summaries in Cassandra. 
There have been brief discussions in the past about moving the summary endpoint to MCS. Generally I'm open to it but would like to better understand what the Web team's changes in requirements for it are. Is there more than just changes in TextExtracts? Do we need to add more logic in JS?

Bernd

On Fri, Jun 23, 2017 at 8:17 AM, Jon Robson <jrobson@wikimedia.org> wrote:

Sounds great to me and a great opportunity to work more with apps!


On Fri, 23 Jun 2017, 02:24 Sam Smith, <samsmith@wikimedia.org> wrote:
It's worth noting the MCS is a collection of services used by the mobile team . It includes endpoints such as `feed` (https://en.wikipedia.org/api/rest_v1/#!/Feed). Why not put `summaries` in there too?

I wasn't aware that the S in MCS was "Services". For those not following along, Marko pointed me at T157059: Rename Mobile Content Service? which is the larger discussion whether the M in MCS is applicable. If we were to add a page summary service to MCS, then I'd argue that the M isn't applicable.

That being said, I am strongly in favour of adding a new Node.js service to that group of services as:
  • It maximises the number of Reading Web engineers who are comfortable with contributing the codebase (not that we're weak in PHP but…).
  • It's relevant experience for the planned rewrite of the mobile site.
  • It places all control of the service in the team's hands.
Only the last point would be true if we were to write the services as a MediaWiki API module.

Any objections from Reading Web or Services?

Corey: I've re-added you to the conversation so that this work is on your radar.

-Sam

--
IRC (Freenode): phuedx
Matrix: @phuedx:matrix.org
Timezone: BST (UTC+1)

_______________________________________________
Services mailing list
Services@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/services