Textextracts has various bugs against it. Apps use it.
Questions to answer:
Duration: 8hrs
What is a summary of the existing bugs?
The most common pain points of the TextExtracts extension seem to be:
At a guess, I'd say that most of the bugs that fall into the latter category could be dealt with quite quickly.
What would we gain by using a parsoid/rest based service?
The Text extraction RFC notes that extract storage – and, presumably, invalidation of that storage – is still an issue, which isn't the case with a RESTBase-proxied service. Other benefits include versioning (!) and automatically gathered performance metrics to name a few.
As I've noted elsewhere, the content translation service does multi-language sentence boundary detection and is proxied by RESTBase. Here though, we also reap the reward of using a service that is being actively developed.
Would it be better to just fix the existing TextExtracts bugs or to create a dedicated service?
This is quite a broad question and, consequently, my answer can only be "It depends." Relying on a Node.js service makes this feature harder to deploy for third-party wikis – though that decision has clearly already been weighed by the ContentTranslation-CXserver team already. On the other hand, I'm not sure if there's even a "current state" of natural language processing in PHP. I think the sweet spot is somewhere in the middle: proxy a fixed up TestExtracts API with RESTBase.
What about former case? Can you elaborate on former case.
What would we gain by using a parsoid/rest based service?
The Text extraction RFC notes that extract storage – and, presumably, invalidation of that storage – is still an issue, which isn't the case with a RESTBase-proxied service. Other benefits include versioning (!) and automatically gathered performance metrics to name a few.
As I've noted elsewhere, the content translation service does multi-language sentence boundary detection and is proxied by RESTBase. Here though, we also reap the reward of using a service that is being actively developed.
Would it be better to just fix the existing TextExtracts bugs or to create a dedicated service?
This is quite a broad question and, consequently, my answer can only be "It depends." Relying on a Node.js service makes this feature harder to deploy for third-party wikis – though that decision has clearly already been weighed by the ContentTranslation-CXserver team already. On the other hand, I'm not sure if there's even a "current state" of natural language processing in PHP. I think the sweet spot is somewhere in the middle: proxy a fixed up TestExtracts API with RESTBase.
That sounds like a good idea. So TextExtracts would make use of RESTBase service if available?
Would it make sense next sprint to address the TextExtracts bugs and then re-evaluate where we are?
What about former case? Can you elaborate on former case.
T59669 contains a lot of examples. I mentioned this case first because I had a go at fixing that bug a while back and some time later started reading about the complexities of SBD.
That sounds like a good idea. So TextExtracts would make use of RESTBase service if available?
Other way around. We augment the TextExtracts API by proxying it through RESTBase and use that API when we know we can (read: use a configuration variable with a sensible default).
Would it make sense next sprint to address the TextExtracts bugs and then re-evaluate where we are?
Yes.
Seems good.
@Jdlrobson @phuedx Should we talk to the services team about:
Other way around. We augment the TextExtracts API by proxying it through RESTBase and use that API when we know we can (read: use a configuration variable with a sensible default).
If we're going to route all that traffic to there we better make sure it's a good idea first.
(Just for my own clarification, as I understood it: access would be through restbase from the client side. Restbase would proxy and cache to an augmented textextracts api)
All of 'em look good @Jdlrobson. They all look like they can be fixed in one place too: the ExtractFormatter class.