SessionManager:
Except for the lack of a client-specified TTL, this proposal looks like it has functionality sufficient to meet the needs of SessionManager.
Lack of support for a client-specified TTL isn't critical here. The main problem would come if the service TTL is less than half of the client-specified TTL, as that would prevent SessionManager's refresh logic from working.
CentralAuth:
CentralAuth uses the session storage backend for its own session-like data. It seems to have similar requirements as core SessionManager.
OAuth:
OAuth uses the session storage backend for storing tokens for its authentication process. For the most part it looks like this proposal has functionality sufficient to meet its needs, with two caveats:
- OAuth uses a "set only if unset" call in several places. While that could be implemented as a GET to check unsetness followed by a PUT, such a mechanism is open to races.
- OAuth seems to rely on short timeouts for security-related features. The service not honoring client-specified timeouts might allow things to be used for much longer than intended (or prevent nonce reuse for much longer than intended).
BagOStuff:
All of the above interact with the storage service via the BagOStuff PHP interface, and it's reasonable that people maintaining such code would expect the features of BagOStuff to generally work and might be surprised if the BagOStuff backed by your service doesn't.
Fortunately, the base BagOStuff class seems to make very few assumptions of the backend. The main shortcomings are already noted above: client-side TTLs and a non-racey implementation of add()
. Implementing those two features should make almost everything else work reasonably well:
getWithSetCallback()
doesn't seem to be documented as such, but I believe the intention is that the callback is supposed to be a lookup where any races would return the "same" data.getMulti()
andsetMulti()
don't seem to offer snapshot or atomicity guarantees, they're just sugar for a loop doingget()
orset()
.lock()
is built on top ofadd()
and short TTLs, andunlock()
is justdelete()
.merge()
by default useslock()
, although if you implement CAS it could use that instead.incr()
useslock()
,decr()
is just a negatedincr()
, andincrWithInit()
usesincr()
andadd()
.
The only other thing is changeTTL()
, which by default is racey. I don't know why it doesn't use lock()
.