Talk:Requests for comment/Storage service
It's been a while since I've been plugged into Mediawiki development, so I'm really excited to see the direction you're headed (i.e., the Service Oriented Architecture). I'm curious, in the requirements I don't understand what the consistency bullet is talking about. Can you give an example of an internal and external url and how they could be the same and different? Thanks -- Brandon CS Sanders (talk)
- Hi Brandon, thanks for your feedback! This is a good place for feedback as it is easy to find along with the RFC.
- An example for consistency of internal and external urls would be both sharing the same structure. Internal
/wiki/_api/v1/pages/Main_Page?rev/latest/html. The idea is that apart from a slightly different prefix the interesting part of the API is all the same, so you only need to learn one version.
- The part about the content is about using relative links (absolute links would need rewriting) and making them work with <base href=".."> or percent encoding of slashes in page names, and similar mechanisms in JSON. We should be able to just use the same cached or stored content internally and externally without expensive post-processing. -- Gabriel Wicke (GWicke) (talk) 03:10, 1 March 2014 (UTC)
From the Arch summit notes in late January 2014: "Rashomon will be tested in production soon. There is still some implementation work to be done. (buckets, auth, revision store). 2 months?"
From Gabriel in IRC today:
- "for our use case rashomon does pretty much all that we need initially... the parsoid integration still needs work though, Arlo is working on that this week....apart from that you can peruse User:GWicke/Notes/Storage/Cassandra_testing"
Timeline and external facing API
ECT would like for their planning/participation:
- What is the timeline estimates for Rashomon at this point?
- Documentation requirements and availability for external (and internal) facing use to make it discoverable/findable by external use?
- @Sharihareswara (WMF): I discussed this with Quim in the office a while ago. The initial Rashomon deployment will be small-scale and won't need major documentation efforts beyond an expanded README. The Service / REST API team planned for next fiscal will develop Rashomon into a more general-purpose storage service for wider use. At that point we'll want to put more effort into systematic documentation. Hope that helps. -- Gabriel Wicke (GWicke) (talk) 19:45, 13 April 2014 (UTC)
We are still looking for a really good name for the storage service. Currently it's called Rashomon, but that's fairly specific to versioning & less fitting for a more general bucket-based storage service. Here are some candidates:
- bucketstore (short 'bs')
- some play on hoarding?