DOM et DSP : deux API Javascript intéressantes poussées par Opera

Posté par (page perso) . Édité par baud123, Xavier Claude, Benoît Sibaud, Florent Zara et Lucas Bonnet. Modéré par Lucas Bonnet. Licence CC by-sa
Tags : aucun
20
5
jan.
2013
Internet

Il y a quelques temps une API UPNP était poussée par Opera vers le W3C pour qu'elle soit spécifiée officiellement. Aujourd'hui, ils proposent aussi un autre brouillon d'API, cette fois-ci orientée DSP et accélération des calculs.

Petite présentation dans la suite de cette dépêche.

NdM : merci à Gui13 pour son journal.

Network Service Discovery API

C'est tout simplement une API qui permet, en Javascript (dans une page web quoi), d'accéder aux machines de votre réseau qui sont compatibles UPNP. Ça va de votre PC Linux sur lequel tourne XBMC à votre NAS qui partage votre collection musicale et vidéo, en passant (surtout) par votre télévision connectée et votre smartphone qui contient les dernières photos de Bibi.

Le protocole UPNP repose sur deux socles :

  • le protocole de découverte de clients sur un réseau local SSDP
  • une grammaire en XML-RPC (SOAP) qui passe ensuite dans les tuyaux pour faire discuter tous ces clients. Chaque client expose les fonctions qu'il supporte (Rendering, Fournisseur de contenu, etc.), et attend une interaction quelconque.

Le protocole en lui-même est (très) verbeux, mais est pris en charge par un ensemble grandissant de matériels.
Pour vous donner un exemple d'usage, on peut, depuis son smartphone, découvrir son NAS et sa TV et agir comme un contrôleur : dire à la TV de lire un contenu fourni par le NAS, le tout depuis son canapé. Une télécommande "++" quoi, avec contrôle complet de la lecture : play/pause/skip/volume.

Malheureusement, les logiciels compatibles UPnP ne sont pas légion et, surtout, généralement très limités. Excepté des gros pontes comme XBMC, qui fait le café avec, il n'existe pas de client léger et pratique pour gérer ce protocole.

La norme que propose Opera permet de faire tout ça dans un navigateur, avec le confort que ça implique.

Une version d'essai d'Opera qui implémente ce draft d'API peut être téléchargée et il y a un exemple de fonctionnalité.
Pour avoir testé, c'est pas trop mal et, si ce simple exemple permet de faire déjà autant, j'imagine même pas la suite.

Je vois déjà des logiciels « headless » dans des petits boitiers qu'on branche n'importe où, genre domotique avancée, et qui broadcastent leurs capacités sur UPnP et leur interface en HTML statique ; le tout chopé par ma tablette et roule !

DSP API

On touche ici à un tout autre sujet, qui est le calcul hautes performances dans le navigateur.

Opera propose une API de calculs parallélisables, comme ce qu'on trouve dans OpenCL ou dans les instructions CPU spécifiques, qui permettent d'accélérer en hardware les calculs sur des matrices.

Ça sert dans beaucoup d'endroits, du genre dans le décodage vidéo (H264, DivX etc.), les filtres audio en temps réel, la SDR et aussi en 3D.

L'API semble assez propre, et relativement réduite et il existe déjà une implémentation fonctionnelle en NodeJS (en revanche, elle ne parallélise pas les calculs si j'ai bien compris son code… dommage).

Le blog où j'ai trouvé ça parle aussi de la version de RiverTrail, qui est un projet conjoint Intel/Mozilla et qui, elle, utilise réellement OpenCL et la parallélisation des calculs sur GPU. Elle semble plus généraliste (n'importe quelle opération « pure » peut être parallélisée), mais ça pourrait faire l'objet d'un autre journal…

En tout cas, il semblerait que les calculs parallèles soient un gros sujet pour l'évolution de Javascript, qui est cantonné au mono-thread depuis des lustres.

J'imagine en utilisation de cette API des filtres « temps-réel » sur les vidéos HTML5, sur des images ou sur de l'audio, voire une génération en temps réel d'un JPG. Probablement aussi pas mal d'analyse de signal (voir le lien SDR au-dessus), qui sont cantonnés pour le moment à des logiciels dédiés.

Conclusion

En gros, malgré leur fermeture logicielle, Opera est quand même assez impliqué dans les standards, ce qui je trouve est une bonne chose.
Les 2 API présentées ici remplissent un vide dans les fonctionnalités des navigateurs et permettront des choses assez intéressantes.
L'API UPnP, surtout, qui va ouvrir tout un tas de possibilités en terme d'interface utilisateur.

Si vous avez d'autres informations sur des évolutions sympas dans le Javascript, rendez-vous dans les commentaires.

  • # UPNP

    Posté par (page perso) . Évalué à  2 .

    Les fonctionnalités développable avec sont intéressantes, mais en rendant la décourverte de l'ensemble du réseau par HTML, on multiplie aussi les possibilité de failles…
    En tous cas pourquoi pas, à condition de ne pas se limiter à une simple télécommande justement, car cette application évidente est déjà possibles de multiples façon et ne change plus grand chose à notre quotidien.
    La parallélisation des calculs devrait avoir ahma un impact plus rapide sur nos habitudes en accélérant rapidement le rendu du JS.

    Remarque, en combinant les deux (parallélisation et UPNP), nous pourrions imaginer faire des réseau de calculs temporaires permettant d'obtenir des rendus vidéos plus agréables sur tous les appareils!
    Après il faut voir tout de même si plusieurs smartphones et un ordinateur ensembles, l'ordinateur ne verrait probablement pas ses capacités augmentées de manière significatives tandis que les smartphones perdraient rapidement de la batterie.
    L'impact sera donc faible pour madame Michu, mais bien plus important dans les bureaux industriels ou des calculs pourraient tirer profit de l'ensemble des machines en réseau.

    • [^] # Re: UPNP

      Posté par (page perso) . Évalué à  6 .

      les smartphones perdraient rapidement de la batterie.

      On peut aussi voir l'inverse: que ton téléphone découvre les ordis du réseau local et leur distribue des taches: par exemple identifier les personnes dans tes photos, compresser une vidéo pour l'envoyer sur Youtube, voire la transcoder en temps réel pour l'envoyer sur la TV.

      Tout ça est déjà possible par le protocole UPnP, et l'implémentation dans le DOM va probablement permettre tout un tas de choses intéressantes.

      J'imagine aussi que la norme pourra s'exporter dans d'autres machines JS: NodeJS et autres logiciels compatibles CommonJS, ce qui rendra la chose un peu plus simple à utiliser.

  • # Titre

    Posté par (page perso) . Évalué à  4 .

    J'aurais bien remplacé le titre par "UPnP et DSP: 2 API Javascript poussées par Opéra", pour être plus clair.

    Je trouve que "DOM et Javascript" est un peu générique..
    Si un admin veut bien changer?

    • [^] # Re: Titre

      Posté par (page perso) . Évalué à  2 .

      ok, corrigé. Un modérateur suffit, pas besoin d'un admin :-)

  • # Opera et non Opéra

    Posté par . Évalué à  2 .

    pas d'accents

  • # **LA** plateforme

    Posté par (page perso) . Évalué à  1 .

    Ça risque d'être utile à FirefoxOS tout ça… (et à Tizen/Open WebOS/Ubuntu Phone/etc)

    Et nos navigateurs web deviennent de plus en plus compliqué. J'ai déjà vu des critiques négatives à ce sujet et je vous le demande: à quand le café dans le navigateur? La complexité d'un navigateur web semble beaucoup augmenter ces derniers temps…

    Le web devient en quelque sorte «LA couche d'abstraction ultime» et je redoute l'arrivée en masse de SaaS (logiciel comme service). Les jeux vidéos en Javascript ça risque d'arriver, et grâce à l'API DSP encore plus vite.

    En fait, le navigateur web devient une énorme machine virtuelle orientée graphique et réseau, qui peut ouvrir n'importe quel «programme» accessible via Internet.

    Pour finir, je ne peux que saluer l'action d'Opera en faveur d'un web ouvert. J'aimerais pouvoir en dire autant d'autres navigateurs:
    — Internet Explorer: fais chier tout les webmasters, DNT activé par défaut ce qui tue un peu son intérêt, Mmm ActiveX et Silverlight, dans IE 9 bureau Flash seulement sur les sites sur liste blanche
    – Chromium/Chrome: API spécifique (notifications sur le bureau par Gmail par exemple), Flash intégré de base dans Chrome
    – Safari: pas grand chose à dire, je me souviens juste qu'une démo sur le site d'Apple présentait des fonctionnalités spécifiques à Safari comme de l'HTML5

    Prêts? Trollez!

    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: **LA** plateforme

      Posté par (page perso) . Évalué à  4 .

      hromium/Chrome: API spécifique (notifications sur le bureau par Gmail par exemple)

      C'est aussi en cours de standardisation http://www.w3.org/TR/notifications/

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: **LA** plateforme

        Posté par (page perso) . Évalué à  2 .

        Mea culpa, mais bon quand dans Gmail on te dis que ça marche que dans Chrome, on a le droit de se poser des questions…

        Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: **LA** plateforme

          Posté par (page perso) . Évalué à  3 .

          Parce que seul Chrome implémente la (pas encore) norme. Si je me souviens bien, Firefox avait réfléchis à l'implémenter quand elle n'était qu'un brouillon (pas encore soumis au w3c je crois), mais ils ne l'avait pas fait parce qu'ils trouvaient qu'il y avait trop de moyen de spammer l'utilisateur, ou pire, de le phisher en se faisant passer pour une notification d'une autre applications. Je ne sais pas si depuis, ça c'est amélioré de ce côté.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: **LA** plateforme

      Posté par (page perso) . Évalué à  2 .

      J'arrive après la bataille mais

      à quand le café dans le navigateur?

      Il y a bien le protocole HTCPCP
      http://fr.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol
      mais il manque toujours d'appareils compatibles.

      • [^] # Re: **LA** plateforme

        Posté par (page perso) . Évalué à  1 .

        C'est déjà implémenté dans Emacs; à quand systemd?

        Écrit en Bépo selon l’orthographe de 1990

  • # Ironie inside ou bien ?

    Posté par . Évalué à  0 .

    Les 2 API présentées ici remplissent un vide dans les fonctionnalités des navigateurs et permettront des choses assez intéressantes.

    [Troll]
    Au non!
    Y a encore des features qui ne sont pas dans les navigateurs ?
    [/Troll]

    Il faut vite corriger cette anomalie…

    • [^] # Re: Ironie inside ou bien ?

      Posté par (page perso) . Évalué à  1 .

      Cf. mon commentaire au dessus.

      je vous le demande: à quand le café dans le navigateur?

      Un navigateur c'est déjà Turing complet, le seul truc qui manque c'est systemd pour le café.

      Mais ouais, aujourd'hui pour faire un navigateur web de zéro et implémenter HTML5/CSS3 et tout ça, même en partant d'un moteur de rendu, c'est extrêmement long et compliqué… (sans compter l'accès à l'OS via Javascript)

      Écrit en Bépo selon l’orthographe de 1990

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.