Shared Worker : comment se déroule la connexion ?

Bonjour,

J'ai regardé un peu sur le net mais la doc (notamment MDN de Mozilla) ne précise pas spécifiquement comment se déroule le partage des messages entre pages qui partagent un même SW (protocole particulier, comment sont sérialisés les données, etc).

Je note que les ports sont ouverts en local : j'imagine la connexion déjà active (c'est-à-dire que l'on a un couple de ports ouverts à chaque nouvel onglet, et non pas un port par thread qui communique avec le thread du SW), donc sans possibilité d'émettre depuis une autre application ?

Je rêve peut-être mais un même SW entre plusieurs navigateurs (ou même une application tout à fait différente), ce serait chouette... notamment pour utiliser les fonctionnalités physiques de l'ordinateur via un logiciel qui exploite les ressources matériels et rebascule des données à l'onglet, sans dépendance du navigateur.

Si vous avez une doc sous la main qui détaille davantage le fonctionnement "réel" des web sockets en bas-niveau (socket), je suis preneur !

Bonne journée à tous,

Julien.

C’est vrai que le MDN ne pointe pas vers la doc de postMessage qui est le mécanisme sous-jacent.

Note qu’un worker, même partagé, reste dépendant d’un contexte d’exécution JS et donc d’un moteur JS. Les différences d’implémentations (par exemple Spidermonkey pour Firefox, V8 pour Chrome) rendent techniquement difficile de partager un worker entre différents navigateurs. Pour l’instant je n’ai pas connaissance que ça ait été tenté.

Les objets JS transmis par postMessage sont sérialisés (voir clonage structuré). Comme les contextes d’exécution sont différents, des mécanismes de sécurité entrent en jeu, avec notamment la notion de propriété : un objet appartient à un contexte, et en particulier une fonction ne peut pas être exécutée si elle provient d’un autre contexte. C’est la raison pour laquelle la sérialisation ne transmet pas les fonctions.


Je pense que ce que tu cherches à faire ressemble plus à un schéma « classique » de serveur local (par exemple un débogueur). Un grand nombre de langages (PHP CLI, Python, Ruby, Node.JS, …) incluent une bibliothèque ou une extension pour créer un serveur HTTP simple qui tourne dans un terminal. Tu y accèdes alors en faisant de simples requêtes ajax, et là peu importe le navigateur.

Peux-tu nous en dire plus sur tes objectifs ?

Pour être honnête pas vraiment d'objectif précis en tête, je travaille à un projet de logiciel de gestion de connaissances (dans le domaine de la décision publique) qui intègre une version du protocole NNTP, SMTP et d'IMAP, développé en Python (3.5) avec une BDD SQLite (pour des raisons de rapidité de développement, le but étant une intégration avec n'importe quelle BDD compatible SQL). L'idéal est de fournir en plus une interface web (en websocket, pour des raisons d'une plus grande flexibilité des échanges) qui, quant à elle, serait plutôt sur NodeJS compte tenu de la grande souplesse entre serveur et client offerte par SocketIO.

Les SW m'intéressent pour plusieurs niveaux : un script JS unique qui gère l'authentification, le log ainsi que les échanges avec le serveur, avant de rebasculer le travail à des Wk dédiés aux usages, ainsi qu'aux pages ouvertes (probablement une par cœurs de métier). En gros, chaque thread pourrait être développé indépendamment des autres, facilitant le développement rapide et organisé en groupe de développement.

Pour l'anecdote, j'ai sorti un bouquin cet été (Intelligence Politique), qui évoque les grandes lignes du projet.

Mon but serait éventuellement d'avoir un point unique qui soit une sorte de "tête pensante" pour la partie client par un navigateur web ; les plus grandes fonctions étant de toute façon déjà fournies par les clients des protocoles NNTP, SMTP ou IMAP (j'ai opté une compatibilité renforcée avec Thunderbird). Les SW ne me semblaient pas mal mais effectivement probablement pas orientés vers des tâches plus spécifiques utilisant les sockets.

Pour postMessage, je n'avais effectivement pas détaillé la page, même si elle reprend pas exactement l'implémentation dans le navigateur, c'est une bonne piste (merci !). Noté pour la sérialisation.

J'espère ma réponse claire, j'ai encore des points non-arbitrés dans mon projet...