Realtime configuration

Cristal
1

Hi all,

Currently, the configuration of real-time in Cristal is as follows:

  1. check for the presence of a realtimeURL key in the current configuration
  2. if the key is not found, real-time is not initialized (e.g., when opening an editor)
  3. if the key is found, a realtime connector is initialized:
  • using TiptapCollabProvider for Tiptap
  • using HocuspocusProvider for Blocknote

The realtimeURL is currently targeting an HocuspocusServer.
But, when connecting Cristal to an XWiki backend, we’d like to use the soon-to-be-integrated Yjs real-time endpoint (see https://github.com/xwiki/xwiki-platform/pull/4361).

Therefore, we’ll need to adapt the selected real-time connector to the configuration.

Note: the proposal below is only for Blocknote as Tiptap is expected to be deprecated anytime soon.

Option 1: explicit configuration

Introduce an optional realtimeHint (with a default to the existing hocuspocus connector). When the hint is defined, the a connector is resolved based on he provided hint.
Of course, the realtimeURL needs to be adjusted when the realtimeHint is changed.

Option 1.1: flat

Keep the current format where all configuration keys are at the same depth level.
Since realtimeHint is optional, this is not a breaking change.

{
  "XWiki": {
    "realtimeURL": "https://localhost:8093/collaboration",
    "realtimeHint": "xwiki"  
  }
}

Option 1.1: nested

The real-time values are nested below a root realtime key.
This is a breaking change, but I believe this is making the configuration easier to read.

{
  "XWiki": {
    "realtime": {
      "url": "https://localhost:8093/collaboration",
       "hint": "xwiki"
    }
  }
}

Option 1.2: nested + backward compatibility

Same as option 1.1 but we keep supporting the realtimeURL key when the realtime key is undefined.

Option 2: deduce from the backend id

Assuming each backend has exactly a single realtime connector, the connector is not resolved by a hint, but by the id of the current backend.
When a backend does not define a specific realtime connector, the default HocuspocusProvider is used.

Note that choosing option 2 does not prevent to add option 1.x later.
Meaning that in the absence of a realtime hint, but in the presence of a realtime url, the connector would be resolved by backend id.

WDYT?

I’m +1 for option 2 for now as its is enough for our current needs.

1 Like
2

What do you mean by “backend ID”?
Also, I imagine situations where backends could have multiple realtime connectors, configurable based on the user’s needs (internal server, webrtc, etc.)

I would personally vote for option 1.1, I’m not sure we need to ensure backwards compatibility given the very low usage of Cristal outside of XWiki SAS currently.

3

I mean the configType key in the configuration.

4

I don’t get how that would work? If the ID is unknown, say, MySuperBackend, which provider to you choose? You directly fallback to HocusPocusProvider?

5

Yes, see:

6

I wasn’t sure about that as your quoted message implies that the backend itself defines the realtime provider, as opposed to being derived from its ID.

So I maintain my vote for option #1.1 :slight_smile:

7

Option 1.1 implemented.

1 Like