daniel added a comment. In https://phabricator.wikimedia.org/T107595#1676115, @GWicke wrote:
> @daniel, your revised version seems to focus even more on implementing > storage systems, change propagation etc, rather than defining a data access > interface for MediaWiki, which can be backed by services. I defined several interfaces that can be backed by whatever service you like. None of them is bound to an SQL backend. In Level II I propose a DB schema that could be used as a default storage mechanism for multiple Content objects per revision. This could serve as a baseline implementation, but the rest of the proposal does not at all depend on this being done in SQL. > Could you clarify how you see this relate to ongoing efforts with similar > goals and use cases like > a) RESTBase offering a lot of the storage & API functionality (beyond blob > storage), - The RevisionContentLookup interfaces could be implemented on top of RESTBase, to provide high level access to Content objects for a given revision. My understanding of RESTbase is a bit blurry, but I suppose that would fit with the "pagecontent" concept in RESTbase. - The BlobStore interface could be implemented on top of RESTBase, to provide a low level storage mechanism for content blobs. - A RESTbase request handler could be implemented on top of a RevisionContentLookup service - A RESTbase request handler could be implemented on top of a BlobStore service I'm not sure which of we would want. RESTbase access to RevisionContentLookup sounds pretty good. A BlobStore backed by RESTbase also seems an obvious win. > b) the event bus (https://phabricator.wikimedia.org/tag/eventbus/), > dependency tracking and change propagation work in > https://phabricator.wikimedia.org/T102476 and friends, and No direct relationship. The current architecture calls for each blob to be identified by a URL; For dependency tracking, we would also want URLs for high level revision slots, especially for derived content (since it depends on whatever it was derived from). RevisionUpdater is intended to allow derived content to be updated when dependencies change. How the notification or re-calculation works is not part of this proposal. > c) the Virtual Rest Service abstraction layer > (https://phabricator.wikimedia.org/T112553)? Same as for RESTbase, really: - The RevisionContentLookup interfaces could be implemented on top of VRS, to provide high level access to Content objects for a given revision. - The BlobStore interface could be implemented on top of VRS, to provide a low level storage mechanism for content blobs. - A VRS backend could be implemented on top of a RevisionContentLookup service - A VRS backend could be implemented on top of a BlobStore service Again, I'm not sure which one we would want, and I'm not yet convinced VRS is a good idea at all. TASK DETAIL https://phabricator.wikimedia.org/T107595 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, Wikidata-bugs, aude, Jay8g, bd808 _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
