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. ## 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 ### 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. It uses PHP's [[ https://secure.php.net/manual/en/function.serialize.php | serialize() ]] and [[ https://secure.php.net/manual/en/function.unserialize.php | unserialize() ]] for the body of `PUT` and the response of `GET` respectively, which isn't ideal (JSON would be better), 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. If it is not possible to make backward-incompatible changes to RESTBagOStuff, we could always provide compatibility using `(Content-Type|Accept): text/plain`. ### 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 iIntegrating w/ MediaWikiwiki 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 idealIt uses PHP's [[ https://secure.php.net/manual/en/function.serialize.php | serialize() ]] and [[ https://secure.php.net/manual/en/function.unserialize.php | unserialize() ]] for the body of `PUT` and the response of `GET` respectively, which isn't ideal (JSON would be better), 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. If it is not possible to make backward-incompatible changes to RESTBagOStuff, we could always provide compatibility using `(Content-Type|Accept): text/plain`. ### 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.