daniel added a comment.
In https://phabricator.wikimedia.org/T107595#2265186, @GWicke wrote: > >> In addition to title and revision (which I assume remains an integer), we'd need an optional v1 UUID parameter to retrieve specific renders, in both the request & response interfaces. > > > > > I have thought about this, too. My solution is to encode this in the slot name. So you could have an html.canonical (sub)slot, and a html.29e68f78-8765-49f8-86d5-dfc438d459fe, or html.en, or whatever. > > Hmmm, this sounds like a rather ugly hack. I thought the 'slot' is identifying the kind of content, and is not some general-purpose string that is used to append otherwise missing parameters, and differs with each render. The slot name defines the function or disposition of the content. I think "english html representation" fits that bill. Since we want to associate some meta-info with slot names (content model, primary orderived, blob store to use, etc), we'd have a stable prefix plus an optional dynamic suffix. I think this is conceptually sound, and allows for nice things like finding all html.canonical slots in the database easily. Putting hashes or uuids in there is less pretty, I agree, but still not horrible. When we start encoding JSON in there, then something went wrong indeed... > I would argue that it is a case of finding an abstraction at the right level. A simple blob store is a very low-level abstraction, and severely limits the backend's abilities to optimize storage, distribution & consistency. It also limits the backend's usefulness as an API in its own right. A narrow and dumb interface for the BlobStore is quite intentional. I want to be able to *easily* implement a BlobStore based on the file system or CDB or whatever. Yes, it's fairly low level, but I think we should have it. And I think we should have such a low level BlobStore that is backed by RESTBase. But perhaps RESTBase can also implement a more high level interface, for managing slot information. But I think that should be kept separate from the intentionally low level BlobStore interfacce. > Instead, I think we should clearly define the API for each slot to provide / consume > > - page id, > - page title, > - revision id, and > - a UUID / hash / etag. Every //slot//, yes. Every //blob//, no. The BlobStore should not know or care about these things. I guess that is where we disagree. > This makes sure that backends can continue to implement higher-level functionality & important optimizations. This should be part of the API, and not a case of a "leak". That said, backends *can* choose to ignore all of this (but the UUID / hash). Yes, that's the kind of high level functionality a RevisionStore would provide. If you want to do that in RESTBase, then you'd have to implement a RESTBase RevisionStore (or RevisionSlotStore, if we introduce an intermediate layer of abstraction). My point is that we shouldn't have all the meta-info in the //lowest// layer of abstraction of storage. And BlobStore is the lowest in this context. And I believe we should indeed have such a low level abstraction layer, if only to encapsulate what's there already: the text table, and external store. > A minimum set of metadata (like the versioned content-type) should always be provided. It would be nice to model this in a way that's compatible with normal HTTP headers, as stored & returned by services like RESTBase. Our baseline implementation is just what's in the text table. The next level implementation is just what ExternalStore has. Neither of them can handle or provide meta-data. Our interface needs to be compatible with that baseline. TASK DETAIL https://phabricator.wikimedia.org/T107595 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808 _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
