Após mais de um ano no GitHub, o projeto Streams foi agora adotado pela WHATWG no esforço para padronizar a API de web streaming. O projeto é liderado por Domenic Denicola, o homem que começou o trabalho no Promises, atualmente parte do próximo ECMAScript 6.
O propósito da API é prover o mapeamento de primitivas I/O em baixo nível para "criar, compor e consumir streams de dados". Estes são destinados a serem streams mais puras que podem ser usadas como base para outras APIs de alto nível, tais como File I/O, Socket, multimídia ou comunicação entre processos. A razão principal por trás dos streams é ser capaz de acessar e obter o dado na web conforme necessidade, sem precisar procurar em toda a memória.
O padrão propõe três tipos de streams: Readable (Legível), Writable (Gravável), e Transform (Trasformável). Enquanto os casos de uso dos streams readable e writeable são óbvios, o stream transform pode ser usado para encriptar ou decriptar dados sob demanda, compressão ou descompressão de imagens, ou aplicar filtros em vídeos.
Os Streams trabalham com pedaços da informação, que representa a unidade básica do dado que um stream manipula. Um pedaço pode conter dados binários ou textos, e um stream pode combinar pedaços de diferentes tipos de dados. Atualmente é debatido se um stream deve conter dados do tipo do objeto ou não.
Os Streams são encapsuladores de fontes de dados básicos. Existem dois tipos de tais fontes para streams do tipo readable: fonte de pressão - envia dados para o consumidor, juntamente com um mecanismo de pausar ou continuar o processo de envio, e a fonte de tração - que fornece o dado de forma sincrôna ou assíncrona baseado na requisição de um consumidor. Os Streams provêem uma interface unificada para ambos tipos de fontes.
Um produtor envia dados para um stream do tipo gravável, que encapsula uma forma de refinamento do dado. A Stream enfileira as sucessivas escritas, passando então para serem refinadas uma a uma.
Os streams do tipo Transform trabalham canalizando um stream do tipo readable em um do tipo writable. Múltiplos streams de transformação podem ser canalizados conjuntamente, formando uma cadeia de canalização. A canalização utiliza um mecanismo de pressão contrária (backpressure) baseado em sinais para manter todos os streams informados se um dos streams na cadeia esta sobrecarregado. Cada stream utiliza uma abordagem com buffer para manipular o dado, tendo pedaços de dados mantidos em uma fila até que o tempo deles cheguem e eles sejam transferidos para o consumidores adjacentes. O mecanismo de pressão contrária é baseado nestas filas e na estratégia de enfileiramento. Um exemplo de tal estratégia consiste em gerar pressão contrária na qual um dos streams tem três ou mais pedaços na fila.
O padrão vem com a implementação de referência e testes escritos em ECMAScript 6 e traduzida e compilada para ECMAScript 5 utilizando Traceur. Existem trabalhos iniciais na inclusão do suporte a Streams no Chromium.
Falamos com Denicola para descobrir mais detalhes sobre o projeto:
InfoQ.com: Entendo que streams são úteis, mas eles já estão em todo lugar na web. Por que uma nova API de streaming?
Denicola: Os Stremas ja fazem parte da web, mas infelizmente eles não estão expostos para todos os desenvolvedores. Por exemplo, quando fazemos um XMLHttpRequest, não há uma maneira de obter a reposta sem que todo o dado tenha sido armazenado na memória primeiramente. Isto significa que até mesmo quando o navegador pode utilizar técnicas de streaming para a implementação, por exemplo no stream de <video>, não há uma maneira que os desenvolvedores possam fazer por si mesmos utilizando XMLHttpRequest. A ideia de Streams Padronizado é fornecer um tipo de dado JavaScript comum que as especificações podem começar a retornar para expor as streams subjacentes que provavelmente já estão sendo usadas, mas ainda não permitindo o acesso aos desenvolvedores.
InfoQ.com: A intenção é incluir isso em uma versão futura do ECMAScript?
Denicola: É uma questão interessante, e de fato falaremos sobre isso no próximo encontro no TC39[1]. Estou dividido nisto. De um lado, I/O streams são uma abstração geral útil e a especificação é escrita em um ambiente-agnóstico de ser. Diversas linguagens com amplas bibliotecas padrões, como C++, Java, e C#, também possuem streams. Por outro lado, a biblioteca padrão ECMAScript tem historicamente sido muito pequena, centrada em primitivas de nível de linguagem e não se preocupa com coisas como I/O. Então adicionando algumas coisas de streams será sem precendentes e um pouco disruptiva.
Meu pensamento atual é que isto faz mais sentido para a especificação ser tratada separadamente e não ser incluída na especificação da linguagem JavaScript. Mas posso imaginar as implementações feitas em muitos ambientes JS, não somente em navegadores. Por exemplo, na ECMA-402 a especificação para internacionalização é inteiramente separada, mas é implementada sobre muitos ambiente JS. O padrão WHATWG URL [3] foi desenvolvido depois da biblioteca URL-parsing do Node.js, porém estou esperançoso que a implementação do Node possa ser atualizada para se adequar o URL padrão com o passar do tempo. E ainda outras coisas como Fetch Standard [4] pode em teoria ser implementado em muitos outros ambientes JS, como uma forma padrão de realizar requisições HTTP.
[1]: https://github.com/tc39/agendas/blob/master/2014/11.md
[2]: http://www.ecma-international.org/publications/standards/Ecma-402.htm
InfoQ.com: Há um trabalho inicial com Streams para Blink. Há uma preocupação se mais alguém possa estar interessado nisto?
Denicola: Sim, definitivamente tenho estado ativo em conversar tanto com a Microsoft como com a Mozilla, que estão muito interessados em ter streams em seus navegadores. Ainda é um pouco cedo, mas existe muito apoio.