Идея реализовывалась и раньше. Просто там производительность, мягко говоря, не очень. Поэтому этот метод хорошо либо просто на поиграться, либо когда альтернатив уже совсем нет.
Я даже помню когда писал нечто похожее несколько лет назад для внутреннего surveillance что бы еще можно было перематывать туда-сюда в браузере.
Даже если по какой-то причине кешировать он её не станет, накапливать в памяти он всё же обязан — ведь это всё-таки GIF, а не потоковое видео. При получении стоп-последовательности он должен начать крутить кадры по кругу.
Вообще-то GIF не обязан быть зацикленным.
И вообще, если почитать GIF89a, то он задумывался скорее для многокадровых презентаций, чем для видеофрагментов.
Как раз с обратной связью проблем никогда не было — ajax. Проблема всегда была с быстрым получением нотификаций от сервера, не спамя его раз в секунду ajax запросами :).
Меня не надо спасать, я использую другие стеки технлогий :). Но я смотрел, как работает long polling на практике. Хороший пример — относительно свежая онлайн-игрушка «Полный Пи», целиком посмотроенная на ajax и long polling. Пропущенные серверные нотификации — это ее основное проклятие на протяжение последнего года. На практие, long polling не очень устойчив к ошибкам сети / ответам всяких кеширующих прокси и прочей ереси. На нагруженном проекте часть нотификаций стабильно клиентом недополучается.
P.S. И преимущества лонг поллинга имеют очень малое отношение к описанному в статье прикольному фокусу :).
Мне вот другое вспоминается: история с режимом HAM (hold-and-modify) в Amiga. Когда разработчики нашли недокументированную возможность графического чипа, который по идее отображал 64 цвета из палитры в 4096 цветов, перевести его в этот режим: HAM — что вдруг вывело Amiga на совершенно иной уровень в плане графики, и обеспечило на определенное время абсолютное превосходство в этой области. Может и не совсем в тему, но от красоты идеи дух перехватило в свое время еще сильнее.
VNC через GIF