Change Details

Once [[ https://phabricator.wikimedia.org/T206010 | questions about the external interface have been answered ]], we'll need to plan the remainder of the implementation, including the use of technologies, and operational semantics.

Once [[ https://phabricator.wikimedia.org/T206010 | questions about the external interface have been answered ]], we'll need to plan the remainder of the implementation, including the use of technologies, and operational semantics. ## Some random notes ### On integrating w/ MediaWiki We should be able to make use of [[ https://doc.wikimedia.org/mediawiki-core/master/php/classRESTBagOStuff.html | RESTBagOStuff ]] on the MediaWiki side. The [[ https://doc.wikimedia.org/mediawiki-core/master/php/classRESTBagOStuff.html#details | API it expects ]] probably isn't ideal, but it seems that it was [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/293554 | created for this purpose ]], and so perhaps we can make a case for changing it. ### Replication semantics Based on the requirements for session storage, we should be able to assume in all cases that //get// and //set// use `ConsistencyLevel.LOCAL_QUORUM` and //delete// uses `ConsistencyLevel.EACH_QUORUM`. However, the service itself will be a very straightforward key-value storage implementation, likely applicable for many future use-cases, not all of which will necessarily be satisfied by these semantics. In the interest of finding balance between future-proofing and YAGNI, we could make the consistency level configurable on a per resource basis. For example, something like: ```lang=yaml,name="config.yaml" ... default_consistency: get: local_quorum set: local_quorum delete: each_quorum ... ``` If this failed to provide enough flexibility for some future use-case, it would be straightforward to extend the API, in a backward compatible way, to accept a per-operation consistency parameter.

Once [[ https://phabricator.wikimedia.org/T206010 | questions about the external interface have been answered ]], we'll need to plan the remainder of the implementation, including the use of technologies, and operational semantics. ## Some random notes ### On integrating w/ MediaWiki We should be able to make use of [[ https://doc.wikimedia.org/mediawiki-core/master/php/classRESTBagOStuff.html | RESTBagOStuff ]] on the MediaWiki side. The [[ https://doc.wikimedia.org/mediawiki-core/master/php/classRESTBagOStuff.html#details | API it expects ]] probably isn't ideal, but it seems that it was [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/293554 | created for this purpose ]], and so perhaps we can make a case for changing it. ### Replication semantics Based on the requirements for session storage, we should be able to assume in all cases that //get// and //set// use `ConsistencyLevel.LOCAL_QUORUM` and //delete// uses `ConsistencyLevel.EACH_QUORUM`. However, the service itself will be a very straightforward key-value storage implementation, likely applicable for many future use-cases, not all of which will necessarily be satisfied by these semantics. In the interest of finding balance between future-proofing and YAGNI, we could make the consistency level configurable on a per resource basis. For example, something like: ```lang=yaml,name="config.yaml" ... default_consistency: get: local_quorum set: local_quorum delete: each_quorum ... ``` If this failed to provide enough flexibility for some future use-case, it would be straightforward to extend the API, in a backward compatible way, to accept a per-operation consistency parameter.