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?
On Thu, Jun 22, 2017 at 6:52 AM Sam Smith samsmith@wikimedia.org wrote:
It's only just occurred to me that I've been making a serious mistake in conflating RESTBase and RESTful services, like MCS, in my recent communications up to and including my initial email.
On Thu, Jun 22, 2017 at 2:43 PM, Marko Obrovac mobrovac@wikimedia.org wrote:
While it could be done in REDTBase as well, I think that this is not a good long-term solution as it introduces a dependency on the Services team for something that you ultimately own the output of.
This is an excellent point.
With the above in mind, I think that the ideal solution is creating a new service for generating page summaries that can be consumed by multiple platforms. Just as with TextExtracts, page summaries are distinct from MCS. It's up to the Reading Web team to decide whether they want to implement it in Node or as a new MediaWiki API module that lives in the Popups extension.
-Sam
-- IRC (Freenode): phuedx Timezone: BST (UTC+1)
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)
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? 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)
Hey all... just acknowledging I saw this. I’m traveling today but reading over and will follow up soon On Fri, Jun 23, 2017 at 7: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? 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)
--
Corey Floyd Engineering Manager Reading Wikimedia Foundation cfloyd@wikimedia.org
+ 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? 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/services
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? 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/services
Hey all - after reading the ticket I see at least a few different conversations going on...
1. A philosophical discussion of what text extracts should be expected to do and what the summary service should be expected to do (dumb or smart) 2. What is a summary and who is the audience of the summary end point (and do we need a reading specific one with special features?) 3. Who should implement and maintain endpoints for Reading clients.
This seems like a lot for phab and email... My suggestion is that the Reading / Services API sync meeting on Thursday seems like the perfect place to talk this out efficiently without throwing an extra meeting on the schedule.
Are there any time pressures here or are we ok to work this out then?
@sam @jon is one or you both good to attend?
Thanks all On Fri, Jun 23, 2017 at 9:09 AM Jon Robson jrobson@wikimedia.org wrote:
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? 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/services
ri-team mailing list ri-team@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ri-team
Hello,
I agree with Corey, we can discuss it in the next sync-up meeting. To throw in some food for thought, in order to move with a new service, its scope should be well-defined; I am not sure that having one service just for manipulating the summary is enough to justify it, but fully agree with Sam that having a shared responsibility inside Readers when it comes to the services you manage is a good move forward, especially since you are all affected by changes made to these end points.
Cheers, Marko
Marko Obrovac, PhD Senior Services Engineer Wikimedia Foundation
On 23 June 2017 at 13:30, Corey Floyd cfloyd@wikimedia.org wrote:
Hey all - after reading the ticket I see at least a few different conversations going on...
- A philosophical discussion of what text extracts should be expected to
do and what the summary service should be expected to do (dumb or smart) 2. What is a summary and who is the audience of the summary end point (and do we need a reading specific one with special features?) 3. Who should implement and maintain endpoints for Reading clients.
This seems like a lot for phab and email... My suggestion is that the Reading / Services API sync meeting on Thursday seems like the perfect place to talk this out efficiently without throwing an extra meeting on the schedule.
Are there any time pressures here or are we ok to work this out then?
@sam @jon is one or you both good to attend?
Thanks all On Fri, Jun 23, 2017 at 9:09 AM Jon Robson jrobson@wikimedia.org wrote:
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? 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/services
ri-team mailing list ri-team@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ri-team
-- Corey Floyd Engineering Manager Reading Wikimedia Foundation cfloyd@wikimedia.org
Services mailing list Services@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/services