Static vs Dynamic context terminology

[toddbaert]

As discussed in today's community meeting, we still don't love the static/dynamic terminology used to differentiate SDKs targeting client vs server. Some background from the proposed spec PR:

### Dynamic-Context Paradigm

Server-side use cases typically perform flag evaluations on behalf of many users, with each request or event being associated with a particular user or client. For this reason, server frameworks typically operate similarly to this:

- the application is initialized with some static context (geography, service name, hostname, etc)
- with each request or event, relevant dynamic context (for example, user session data) is provided to flag evaluations

### Static-Context Paradigm

In contrast to server-side or other service-type applications, client side applications typically operate in the context of a single user. Most feature flagging libraries for these applications have been designed with this in mind. Frequently, Client/web libraries operate similarly to this:

- an initialization occurs, which fetches evaluated flags in bulk for a given context (user)
- the evaluated flags are cached in the library
- flag evaluations take place against this cache, without a need to provide context (context was already used to evaluate flags in bulk)
- functions are exposed on the libraries that signal the cache is no longer valid, and must be reconciled based on a context change, frequently involving a network request or I/O operation

It seems like there's a general consensus these characterizations are adequate, but the names for them are not.

I'd like to use this discussion to brainstorm and vote on some better names. Here's a short list from the meeting, as well as a couple I've heard elsewhere or came up with.

[beeme1mr]

I like the idea of multi-user context vssingle-user context, but I prefer to avoid tying it to a user. I think that's why you added subject, but that isn't resonating with me either. @moredip, we need your wordsmithing abilities! Any suggestions?

[Kavindu-Dodan]

+1 to avoid using the word user (implying a human user/end-user). For example, in a microservice architecture, each service could act as a single context.

[beeme1mr]

It may be worth adding client vs server to the poll.

[toddbaert]

It may be worth adding client vs server to the poll.

It's there already: server context / client context

[Kavindu-Dodan]

Voted for the option mutli-context VS single-context. It keeps the terminology generic enough (i.e- to which entity the context belongs to) and gives clear differentiation on the context usage

[toddbaert]

Thanks to all who voted.

What I've done for a "best of both worlds" solution is to addstatic/dynamic to the glossary, but also add client/server-side SDK, which essentially references the static/dynamic paradigms and explains that client implies static and server implies dynamic.