Enable MessageChannel for guest <--> sidebar communication

[esanzgar]

No description provided.

[robertknight]

Hi Eduardo. While I know that you're still working on this, I've had a read through the current prototype and left some comments.

I have some high-level thoughts:

• The channel setup protocol needs to work in a way that doesn't require the sidebar to request its port for a channel, except for the host <-> sidebar channel. This is because the sidebar doesn't know when the notebook will be opened or how many guests there will be. Instead the host should just send the sidebar its port when a new guest/notebook <-> sidebar channel is created. For this to work, the host needs to know when the sidebar is ready to receive ports. Fortunately the host can already know this because the sidebar requests its port for the host <-> sidebar channel when ready.
• If the above change is made, then the "request" messages can be simplified because they only need to specify the role (guest, sidebar, host, notebook) of the frame requesting the channel. Everything else can be determined by the host [1], assuming that all connections are between the single sidebar and a non-sidebar frame.
• Any code that is used by both src/annotator and src/sidebar in the client needs to live in src/shared. This is to make it easier to understand which environments a particular module needs to operate in, as well as for general module dependency hygiene.
• The changes to make frame-rpc work with MessagePort seems like something that is unlikely to be affected by higher-level changes, so you could move ahead with creating a PR to make that change as a first step to getting this into production.

[1] If the sender is the sidebar, they must be requesting a connection to the host. If the sender is not the sidebar, they must be requesting a connection to the sidebar.

[esanzgar]

This is because the sidebar doesn't know when the notebook will be opened.

A very nice features of the MessageChannel API is that messages are queued until the receiving port is ready. This means that no message is lost and that you don't have to wait until the other port has been received and is ready to send messages.

Here is an example:

const {port1, port2} = new MessageChannel();

// Message can be sent immediately
port1.postMessage('Hello from port1');
port2.postMessage('Hello from port2');

port1.onmessage = ({data}) => console.log(data);
VM408:1 Hello from port2

port2.onmessage = ({data}) => console.log(data);
VM434:1 Hello from port1

port1.onmessage = ({data}) => console.log(data); is equivalent to these two statements together:

port1.addEventListener('message', ({data}) => console.log(data));
port1.start()

So the above is similar to this:

const {port1, port2} = new MessageChannel();

// Message can be sent immediately
port1.postMessage('Hello from port1');
port2.postMessage('Hello from port2');

port1.addEventListener('message', ({data}) => console.log(data));
port2.addEventListener('message', ({data}) => console.log(data));

// Messages are queued until the port is started
port1.start()
VM408:1 Hello from port2
port2.start()
VM434:1 Hello from port1

What this means in practice is that it doesn't matter if sidebar loads before or after notebook frame, all messages will be received.

However, I agree with you, that once the host <-> sidebar communication channel has been established, all other ports required by other channels should/could be sent through the above channel (host <-> sidebar).

[esanzgar]

Thank you @robertknight for all your thoughtful comments and suggestions.

I have made several modifications and added a few responses.

[esanzgar]

I agree about dropping subFrameIdentifier (point 3).

I understand that if we rework the protocol of handling ports (point 2), we could get ride of the channel option and use the port option with three possible values: sidebar, notebook and guest. However, in the future there could be situation when just specifying the name of the requested port could be ambiguous. For example, maybe in the future we want to connect notebook with the sidebar and the host frames. In that case, if notebook frame request the notebook port it is impossible to know if it is requesting the port from notebookToSidebar channel or notebookToHost channel. Although it is a little bit more verbose to have both channel and port options, I believe is more explicit.

Regarding the hostFrame, this is the frame/window that is used to send the hostFrame.postMessage. In our current use cases, this is always window.parent. However, in the future we may allow a situation where a guest frame could be a descendant of host frame (a bit similar to the LMS case), instead of just a direct child.

[robertknight]

What this means in practice is that it doesn't matter if sidebar loads before or after notebook frame, all messages will be received.

Ah, I follow. That's useful. OK, well this simplifies things for us.