Hey all - after reading the ticket I see at least a few different conversations going on...<br><br>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) <br>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?)<br>3.  Who should implement and maintain endpoints for Reading clients. <br><br>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. <br><br>Are there any time pressures here or are we ok to work this out then?<br><br>@sam @jon is one or you both good to attend?<br><br>Thanks all<br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 23, 2017 at 9:09 AM Jon Robson &lt;<a href="mailto:jrobson@wikimedia.org">jrobson@wikimedia.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Essentially we want to be able to do things such as:<div>* Special case summaries for pages such as disambiguation/ potentially list pages </div><div>* Move logic that bolds the title from client side js to the service</div><div>* Improve html summaries to ensure they are well formed html</div><div>* Move/add logic that strips parentheses <br><br>Ultimately the goal is to make page previews dumb and the service smarter.</div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, 23 Jun 2017, 08:59 Bernd Sitzmann, &lt;<a href="mailto:bernd@wikimedia.org" target="_blank">bernd@wikimedia.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+ Reading Infrastructure<div><br></div><div>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. </div><div>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. </div><div>There have been brief discussions in the past about moving the summary endpoint to MCS. Generally I&#39;m open to it but would like to better understand what the Web team&#39;s changes in requirements for it are. Is there more than just changes in TextExtracts? Do we need to add more logic in JS?</div><div><br></div><div>Bernd</div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 23, 2017 at 8:17 AM, Jon Robson <span dir="ltr">&lt;<a href="mailto:jrobson@wikimedia.org" target="_blank">jrobson@wikimedia.org</a>&gt;</span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Sounds great to me and a great opportunity to work more with apps!</p>
<br><div class="gmail_quote"><span><div dir="ltr">On Fri, 23 Jun 2017, 02:24 Sam Smith, &lt;<a href="mailto:samsmith@wikimedia.org" target="_blank">samsmith@wikimedia.org</a>&gt; wrote:<br></div></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div dir="ltr"><div class="gmail_extra"><div class="m_-6264661174281667403m_-5557093368028236478m_3667648088525443978m_-8014917902603279386gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">It&#39;s worth noting the MCS is a collection of services used by the mobile team . It includes endpoints such as `feed` (</span><a href="https://en.wikipedia.org/api/rest_v1/#!/Feed" style="font-size:12.8px" target="_blank">https://en.wikipedia.org/api/rest_v1/#!/Feed</a><span style="font-size:12.8px">). Why not put `summaries` in there too?</span></blockquote><div><br></div></div></div></div></div></div></div></div></div></div></div></span><div dir="ltr"><div class="gmail_extra"><div class="m_-6264661174281667403m_-5557093368028236478m_3667648088525443978m_-8014917902603279386gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>I wasn&#39;t aware that the S in MCS was &quot;Services&quot;. For those not following along, Marko pointed me at <a href="https://phabricator.wikimedia.org/T157059" target="_blank">T157059: Rename Mobile Content Service?</a> 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&#39;d argue that the M isn&#39;t applicable.</div><div><br></div><div>That being said, I am strongly in favour of adding a new Node.js service to that group of services as:</div><div><ul><li>It maximises the number of Reading Web engineers who are comfortable with contributing the codebase (not that we&#39;re weak in PHP but…).</li><li>It&#39;s relevant experience for the planned rewrite of the mobile site.</li><li>It places all control of the service in the team&#39;s hands.</li></ul><div>Only the last point would be true if we were to write the services as a MediaWiki API module.</div><div><br></div><div>Any objections from Reading Web or Services?</div></div><div><br></div><div><b>Corey</b>: I&#39;ve re-added you to the conversation so that this work is on your radar.</div></div></div></div></div></div></div></div></div></div></div><span><div dir="ltr"><div class="gmail_extra"><div class="m_-6264661174281667403m_-5557093368028236478m_3667648088525443978m_-8014917902603279386gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>-Sam</div><div><br></div><div>--</div><div>IRC (Freenode): phuedx<br></div></div></div></div></div></div></div></div></div></div></div></span><div dir="ltr"><div class="gmail_extra"><div class="m_-6264661174281667403m_-5557093368028236478m_3667648088525443978m_-8014917902603279386gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Matrix: <span style="color:rgb(69,69,69);font-family:&quot;Open Sans&quot;,Arial,Helvetica,sans-serif;font-size:13px">@phuedx:<a href="http://matrix.org" target="_blank">matrix.org</a></span></div>Timezone: BST (UTC+1)<br></div></div></div></div></div></div></div></div></div></div>
</blockquote></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
Services mailing list<br>
<a href="mailto:Services@lists.wikimedia.org" target="_blank">Services@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/services" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/services</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div>
_______________________________________________<br>
ri-team mailing list<br>
<a href="mailto:ri-team@lists.wikimedia.org" target="_blank">ri-team@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/ri-team" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/ri-team</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(0,0,0);font-family:sans-serif">Corey Floyd</div><div style="color:rgb(0,0,0);font-family:sans-serif">Engineering Manager</div><div style="color:rgb(0,0,0);font-family:sans-serif">Reading</div><div style="color:rgb(0,0,0);font-family:sans-serif">Wikimedia Foundation</div><div style="color:rgb(0,0,0);font-family:sans-serif"><a href="mailto:cfloyd@wikimedia.org">cfloyd@wikimedia.org</a></div></div></div>