Implementation-related question: why long-lived connections?

[hindmost]

Why do you open a long-lived, never closing connection from each content script to the background script? AFAIU it is used to track changes in the state. But why long-lived connection, not just one-time request via sendMessage?

The offical docs say that:

the background page will not unload until all visible views and all message ports are closed.

So that eventually make the background script persistent even it is declared as non-persistent (event page) in the manifest. Doesn't it?

[tshaddix]

@hindmost That's correct! It essentially will keep the background page open while there is a connection.

The reason I originally used a long-lived connection is around overhead. I made a guess (but never actually tested) that is was less resource intensive to keep a long-lived connection open rather than send an individual message to each page. Sending a message to each page for state updates would require you to query all open tabs, and then call sendMessage on each tabId from what I understand. Long story short - I made a guess on what I thought would be less resource intensive.

[hindmost]

It seems that you talk about the context when the state in extension is constantly changing. But is it common? How often does anything really change in typical extension from the viewpoint of the entire browser? Suppose that some extension is installed but never actually used within browser session, and the extension's state remains unchanged. So is it really necessary to keep background->tabs/popup connections? And even if the extension's state is sometimes updated by user actions, I don't think that keeping long-lived connection is preferred over sending one-time messages. A user may use an extension for a short time, and then don't use it till browser closing.

BTW, it's unnecessary to use messaging (neither one-time nor long-lived) to pass state from background to popups cause they have direct access to background page via getBackgroundPage method.

[tshaddix]

Yep, I am aware of getBackgroundPage. As you mention, this doesn't work on content scripts (https://developer.chrome.com/extensions/content_scripts). Rather than fragment the messaging strategies, we chose to use just one.

But is it common? How often does anything really change in typical extension from the viewpoint of the entire browser? Suppose that some extension is installed but never actually used within browser session, and the extension's state remains unchanged. So is it really necessary to keep background->tabs/popup connections? And even if the extension's state is sometimes updated by user actions, I don't think that keeping long-lived connection is preferred over sending one-time messages. A user may use an extension for a short time, and then don't use it till browser closing.

I'm not sure of the commonality of different extension types, but I can guarantee people are using this extension for things that require tons of updates. Some people are using it for audio visualizations from microphone inputs. Some people are using it from realtime typing feedback. You're right that not all extensions are required to be open at all times.

Are you running into issues with the current version of this package? Is there a performance issue that you're reporting? If you are, please explicitly state the issue so we can dive deeper.

[hindmost]

No, I haven't used your package yet. Sure I realize that it might have some benefits for high load extensions but that's not my case. My extension isn't supposed to be always active and I don't like that your package makes decision for me and chooses most complex way of communication. I think it'd be better if it leaves this choice to me.

[tshaddix]

Ah - now I see. So the root of this request is about allowing your extension to go inactive - not messaging performance. That's definitely something worth discussing.

There are definitely multiple ways to approach this. It seems like you're advocating for adding a messaging strategy for one-time messages that can be configured at run-time. That should be pretty straight-forward.

[hindmost]

Yeah, that's mostly what I meant.
Also, if you'll add the one-time messaging option, I'd suggest to only send syncing message to active tab, not all tabs.