Topic on Talk:Requests for comment/SessionStorageAPI

Note that MediaWiki uses the term "global session" for sessions which are shared between all wikis (ie. CentralAuth sessions), not sessions which are shared between all servers. Maybe that should be qualified somehow to avoid confusion.

Yeah, that will be confusing. Any suggstions?

Cross-DC sessions maybe? Or wiki-global vs. server-global?

I'm confused now. SUL users are unique across all wikis, and each of them can have sessions associated with them per-wiki. However, it is my understanding that this is due to practical implementation details (e.g. different domains).

There's a per-wiki session and a global session. Per-wiki session is what you want to use for most things (an extension writing something into the session on enwiki and the same extension on dewiki should not clobber each other); the global session is used to track global login status. (If you log in on enwiki, then visit dewiki, dewiki will not find a local session, so it will check your global session to make sure you are logged in. There's a CentralAuth cookie, separate from the normal session cookie, and set on the .wikipedia.org domain, that stores the key to that session.)

See SessionBackend::save() for the local session handling code and CentralAuthUtils::setCentralSession() for the global session handling code.

I see the potential for confusion, but I don't quite understand it. Sessions by nature *have* the be the same across application servers and data centers, right? Anything else would just be broken. So there's no need for a special name for this "kind" of session. We should just have the requirement of consistent storage across app servers and DCs as a requirement, and specify the limits (replication delay, etc).

The term "global sessions" should in my opinion be used only for cross-domain sessions. Though "cross-domain session" would probably be a better name :)

For what it's worth: I updated the text to refer to sessions in this context as "valid fleet-wide", in the hopes of avoiding confusion. I think this is only an issue now, in this context, as Daniel points out there'd be no need to ever refer to them as anything other sessions after-the-fact.