Docs in subscribed queries are always considered to be subscribed

[alecgibson]

At the moment, when you create a subscribe query, the query will automatically pass all ops back to the client, regardless of whether it wants to be subscribed or not. This can be quite confusing:

• a Doc that matches a subscribe query will receive 'op' events, even though doc.subscribed === false
• calling doc.unsubscribe() will not actually stop the doc receiving 'op' events

It's possible to make this behaviour a bit more consistent in a few ways:

• check at the server if the client doc is subscribed, and only send ops back in that case
• make connection.get() return new instances of docs rather than cached instances (which I've personally always expected) — this would allow individual Doc instances to be unsubscribed, while query.results stay subscribed

At the very least it might be nice to error in doc.unsubscribe() if the doc matches a query (and therefore cannot be unsubscribed). It may also be nice to change doc.subscribed into a method/getter which checks if it's part of a query, to reflect its "true" state

All of the above changes would technically be breaking.

One nice, non-breaking thing we could potentially do is to just logger.warn() if unsubscribing a doc that matches a query.

[alecgibson]

A controversial solution to this might be to break the Doc API:

• remove doc.subscribe() and doc.unsubscribe() — docs will always be subscribed (so long as they are connected); docs can be "unsubscribed" by destroying
• remove doc.fetch() — single, read-only snapshots can now be fetched with connection.fetchSnapshot(), which is lighter-weight, and doesn't need to remember to call doc.destroy(), etc.

This sort of API change would help to encourage some conceptual boundaries:

• Docs are always subscribed, and always represent the real-time, live doc. This will:
  • remove inconsistency with query subscription state
  • reduce complexity around client-side subscription logic
  • reduce confusion around some edge cases (eg submitting an op from an old, unsubscribed Doc)
• Snapshots are read-only, frozen snapshots that can't be interacted with. This:
  • helps to conceptually separate them from Docs
  • reduces conceptual/performance overheads attached to trying to just perform a one-off fetch

[alecgibson]

Discussed this proposal a bit with @ericyhwang . The main thing we wouldn't be able to do with this is to perform a lightweight one-off fetch and submit an op on the document.

[ericyhwang]

We also discussed how, even with a doc that's not subscribed and not in any queries, it will still receive remote ops if you submit an op and the doc has had remote ops committed in the meantime. So "unsubscribed" really means "I don't actively care about receiving ops in real time (but I might still receive ops anyways)". It's something we could clarify in the docs if it's a point of confusion