How to pass options through to server?

[jandrieu]

We have an operation, for which we need to pass additional options through to the server.

However, in doc.js Doc.prototype.submitOp, the only option value that survives to the server's submit is [source].

Is there some other way to pass that information?

Or would it be welcome if we updated that bit of code to allow the submitOp caller to pass options through to the server?

[alecgibson]

We're (ab)using the op source to pass extra metadata to the server, since the source can technically be a JSON object:

doc.submitOp(op, {
  source: 'user', // nest the source if it matters to you
  options: {...}, // other stuff you want on the server
})

Of course this isn't the most semantic thing to do.

Could definitely discuss a PR that passes more information. Adding the data should be relatively simple; I deliberately added an "extra" .x field to the message, which more stuff could be added to.

The main wrinkle is dealing with op composition: if you're attaching information to a particular op, we'll probably need to force op composition to be turned off.

[jandrieu]

The main wrinkle is dealing with op composition: if you're attaching information to a particular op, we'll probably need to force op composition to be turned off.

Can you say more about this?

In our case, we are passing a signed authorization token, without which the op should not occur.

So, I think you are correct. We need to treat each option as a unique, separately authorized request. We would not be able to apply the authorization from one op to another (because it contains a commitment to the particular op).

Where and how does composition happen in sharedb?

[alecgibson]

We would not be able to apply the authorization from one op to another (because it contains a commitment to the particular op).

To be honest this setup sounds a little odd to me. I'm not sure I understand why you'd authenticate each op individually instead of just authenticating the connection?

Your app architecture aside, ShareDB will by default try to compose — that is, merge — ops that are submitted in quick succession (more formally, while waiting for the server acknowledgement of a currently in-flight op). That means that — by default — an op cannot be considered as a discrete unit, since it might be coalesced onto another op. This all happens on the client.

This behaviour can be manually disabled with the doc.preventCompose flag, with the obvious performance penalty of increased network traffic (although it sounds like in your particular case this is expected), and potentially increased DB storage, network and CPU load (due to having more ops stored).

The previously mentioned submitSource flag works around this by only allowing composing of ops with identical sources, which lets ops compose if the source is equal, allowing some performance gains so long as source isn't unique per-op.