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(a)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(a)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(a)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? <https://phabricator.wikimedia.org/T157059> 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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/services
_______________________________________________