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
_______________________________________________