web-dev-qa-db-fra.com

Qu'est-ce que Streams3 dans Node.js et en quoi diffère-t-il de Streams2?

J'ai souvent entendu parler de Streams2 et d'anciens streams, mais qu'est-ce que Streams3? Il est mentionné dans cet exposé de Thorsten Lorenz .

Où puis-je lire à ce sujet et quelle est la différence entre Streams2 et Streams3.

En faisant une recherche sur Google, je le vois également mentionné dans le Changelog of Node 0.11.5 ,

stream: Simplifiez l'écoute passive et fluide des données (streams3) (isaacs)

node.jsstream
51
Evan Carroll

Je vais essayer ça, mais je me suis probablement trompé. N'ayant jamais écrit Streams1 (old-streams) ou Streams2, je ne suis probablement pas le bon gars pour répondre à celui-ci, mais c'est parti. Il semble que l'API Streams1 persiste encore dans une certaine mesure. Dans Streams2, il existe deux modes de flux fluide (hérité) et non fluide. En bref, la cale prenant en charge le mode fluide disparaît. C'était le message qui a conduit au patch maintenant appelé appelé Streams3 ,

Même API que streams2, mais supprimez la modalité déroutante du commutateur de mode fluide/ancien.

  1. Chaque fois que read() est appelé et renvoie des données, un événement de données se déclenche.
  2. resume() le fera appeler à plusieurs reprises read (). Sinon, pas de changement.
  3. pause() empêchera d'appeler read() à plusieurs reprises.
  4. pipe(dest) et on('data', fn) appellera automatiquement resume().
  5. Pas de passage en mode ancien. Il n'y a que couler et faire une pause. Les flux commencent en pause.

Malheureusement, pour comprendre toute description qui définit assez bien Streams3, vous devez d'abord comprendre Streams1 et les flux hérités

Passé

Tout d'abord, jetons un coup d'œil à ce que les documentaires Node v0.10.25 disent des deux modes,

Les flux lisibles ont deux "modes": un mode fluide et un mode non fluide. En mode fluide, les données sont lues à partir du système sous-jacent et fournies à votre programme le plus rapidement possible. En mode non fluide, vous devez explicitement appeler stream.read () pour extraire des blocs de données. - Node v0.10.25 Docs

Isaac Z. Schlueter a dit en novembre que j'avais glissé des diapositives :

streams2

  • "sucer des flux"
  • Au lieu de cracher des événements 'data', appelez read () pour extraire les données de la source
  • Résout tous les problèmes (que nous connaissons)

Il semble donc que dans streams1, vous créez un objet et appelez .on('data', cb) à cet objet. Cela aurait pour effet de déclencher l'événement, puis vous étiez à la merci du flux. Dans Streams2, les flux internes ont des tampons et vous demandez explicitement des données à partir de ces flux (en utilisant `.read). Isaac précise ensuite comment fonctionne la compatibilité ascendante dans Streams2 pour que les modules Streams1 (ancien flux) fonctionnent.

cale streams1 à l'ancienne

  • Les nouveaux flux peuvent passer en mode ancien, où ils crachent des "données"
  • Si vous ajoutez un gestionnaire d'événements "données", ou appelez pause () ou resume (), puis basculez
  • Apporter des modifications minimes aux tests existants pour nous garder honnêtes

Ainsi, dans Streams2, un appel à .pause() ou .resume() déclenche le shim. Et, ça devrait, non? Dans Streams2, vous contrôlez quand .read() et vous n'attrapez pas de choses qui vous sont lancées. Cela a déclenché un mode hérité qui a agi indépendamment de Streams2.

Prenons un exemple de la diapositive d'Isaac,

createServer(function(q,s) {
  // ADVISORY only!
  q.pause()
  session(q, function(ses) {
    q.on('data', handler)
    q.resume()
  })
})
  • Dans Streams1, q démarre immédiatement en lisant et en émettant (probablement en perdant des données), jusqu'à ce que l'appel à q.pause Conseille à q d'arrêter d'extraire des données mais pas d'émettre des événements vers effacer ce qu'il a déjà lu.
  • Dans Streams2, q démarre en pause jusqu'à l'appel à .pause() qui signifie émuler l'ancien mode.
  • Dans Streams3, q commence comme interrompu, n'ayant jamais lu depuis le descripteur de fichier, faisant de q.pause() un noop, et lors de l'appel à q.on('data', cb), il appellera q.resume jusqu'à ce qu'il n'y ait plus de données dans le tampon. Et puis appelez à nouveau q.resume En faisant la même chose.
44
Evan Carroll

On dirait que Streams3 a été introduit dans io.js, puis dans Node 0.11+

Flux 1 Les données prises en charge sont transférées vers un flux. Il n'y avait aucun contrôle du consommateur, des données étaient lancées sur le consommateur, qu'il soit prêt ou non.

Streams 2 permet aux données d'être poussées vers un flux selon Streams 1, ou pour un consommateur d'extraire des données d'un flux selon les besoins. Le consommateur peut contrôler le flux de données en mode pull (en utilisant stream.read () lorsqu'il est informé des données disponibles). Le flux ne peut pas prendre en charge Push et Pull en même temps.

Streams 3 permet de tirer et de pousser des données sur le même flux.

Grand aperçu ici:

https://strongloop.com/strongblog/whats-new-io-js-beta-streams3/

6
Joe