[ Placeholder epic for now; this may include custom API endpoints, image recommendation pipelines, etc]
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T398494 [Epic] Image browsing: build out the back-end | |||
| Resolved | Spike | bvibber | T398992 SPIKE Image Browsing: Determine how relevant images get included | ||
| Resolved | Spike | lwatson | T398994 SPIKE Image Browsing: Determine what is possible for including text content alongside images | ||
| Resolved | egardner | T400703 Request ImageBrowsing security review | |||
| Resolved | Spike | egardner | T400823 [SPIKE] Image Browsing: Determine how to include relevant images from beyond the immediate page | ||
| Resolved | mfossati | T402271 Image browsing: ensure exclude tags are respected | |||
| Resolved | Spike | ovasileva | T401159 [SPIKE] Image Browsing: Investigate a keyword-based approach | ||
| Resolved | mfossati | T403613 Image Browsing: build the API endpoint for images from other wikis |
Event Timeline
Comment Actions
If we expose MediaWiki REST API endpoints, we can add -beta suffixes to module paths or versions. See T395713: REST: Beta Modules - support beta suffix in module ids and versions.
Thanks @BPirkle for the heads-up, feel free to chime in with more details.
Comment Actions
If we can rely on any existing (or emerging) convention to signal that API endoints we set up for our experiments are not stable, that is great. Then we could still take advantage of other amenities like the API sandbox I assume (which could be useful in testing and development).
@BPirkle, I strongly agree with this from T395713:
Today, experimentation is done in a haphazard manner across a limited set of teams. In many cases, the experimental state is only stated in documentation, which leads to some adoption in production applications.
Having experimental features "accidentally" becoming productionized is exactly what I'm hoping to avoid; many of my initial ideas for the ReaderExperiments codebase we're going to set up are motivated by this.
Comment Actions
(This is mostly copy-paste from my chat with Marco in Slack)
The newer pattern (sorry this is not all documented yet, we're working on it) is to use MW REST "modules", which are effectively collections of API endpoints. We're using ReadingLists as the initial implementation in an extension. Basically, you put your routes into an external json file. This gives you an opportunity to add some metadata, and also gives a nice place to see a clean git history for changes to your routes over time. The -beta would go in the moduleId and version fields, per this experimental change.
Some relevant links:
- ReadingLists extension.json, where a RestModuleFiles entry points at the module file
- the ReadingLists module definition file
And yes, this also better positions you for the REST Sandbox. It is currently "experimental" and only available on a few wikis, but we have plans to make it available everywhere.
We'd be very excited to see another team using all this, and to get any feedback you may have. So when you're ready to start coding, please reach out and we'll be happy to help in any way we can!