Decide who should hold the workspace id: the Workspace model or the Structurizr Client

[ilaif]

[yt-ms]

It seems a bit odd that the client be tied to a single workspace, and this is inconsistent with the Java API.

I'd suggest keeping the workspace ID in the Workspace, and allowing the client to operate across multiple workspaces. Note that we'd need a slightly different solution to being able to lock/unlock a workspace with a with block - maybe do something like with client.lock(workspace):, which is also explicit about what it's doing?

[Midnighter]

I like your idea for a context manager around a lock method!

It's true that the Java API accepts the workspace ID as an argument, however, it does hold the API key and secret which, as far as I know, are also specific to a particular workspace (but maybe I'm wrong on this). That's why I originally decided to put all of that on the settings object.

[yt-ms]

it does hold the API key and secret which, as far as I know, are also specific to a particular workspace (but maybe I'm wrong on this).

Hmmm, good point. I'm hoping to get a licence key shortly that gives me multiple workspaces, so I'll check this out and see whether the key and secret are workspace-specific.

[Midnighter]

I have access to three workspaces through the open source plan and each ID, key, and secret are different.

[Midnighter]

This is actually a duplicate of #11 but more discussion here so I'll close that one.