Kurento — WebRTC со всеми вытекающими. Если он в плане кодирования видео следует стандарту — масштабироваться будет так же дорого.
> не нужно никому 200 долларов отдавать
Хорошая шутка. Welcome отлаживать код на C++/GStreamer и опционально код браузера, расскажете только потом, что было ли это дешевле и проще, чем заплатить людям, которые сделают это за вас.
Вообще, в плане WebRTC надежды не вселяет вообще ничто.
> для каждого готовить свою картинку
Да ну, так никто не делает. Это мягко говоря неоптимально, да и не нужно никому.
Однако, по стандарту WebRTC видео действительно кодируется для каждого клиента персонально. Типа для QOS. Еще одна причина сказать, что WebRTC не очень.
200$ у VoxImplant стоит поддержка. На все остальное у них, я бы сказал, терпимые цены.
Для примера, на наши вебинары(не буду уточнять), разработку+хостинг, у нас уходит 200+к руб/месяц. Цены на закупки железа так и вообще вгоняют в ужас. И это не самый посещаемый проект и не в стадии активной разработки.
Для смертных «в теме» — можно уже сейчас, вопрос цены. Для совсем простых смертных — никогда.
Есть P2P-WebRTC, есть несколько open-source реализаций релейных серверов для WebRTC. Масса геморроя, сложно масштабируется.
Есть VoxImplant, действительно — и должен быть удобнее голого WebRTC. Но вы заплатите за весь гемор из предыдущего пункта и еще чуть сверху на развитие. =)
А Wowza — хороший мультипротокольный стриминг-сервер, но совсем не про то.
Они для другого предназначены, в STUN вообще нет описываемой функциональности и он не спасает от symmetric NAT. И вообще, вы где-нибудь видели standalone клиент для TURN?
Вообще, они все похожи на правду, особенно те, что про buildup of OS threads.
Ну и вообще, они все про архитектуру рантайма Go, которая за прошедший год сильно не менялась.
Ок, идем от начала.
Есть эрланг-проект, собирается ребаром, основным является именно он. На эликсире только прослойка для работы с БД с ecto — абсолютно нормальные требования, на мой взгляд.
Тем более, что ecto — единственная причина вообще заморачиваться.
А дальше начинается ожидаемое. rebar_elixir_plugin не умеет в app-файлы в принципе. ecto из ребара не собирается. То есть, ради использования одной библиотеки мне нужно менять систему сборки проекта. Приехали.
Уже на этом этапе можно закрывать тему, но немного заглянув вперед, мы узнаем, что на каждый чих нужно писать враппер-функцию erlang map -> ecto struct. А то и erlang record -> ecto struct. Что ecto жестко привязан к эликсирному логгеру, как результат нам нужно конфигурить два логгера при старте — потому что у нас уже есть логгер, какой проект без логгера.
Да, я не умею готовить эликсир. Но мне не кажется, что интеграция с хостовым языком должна выглядеть так.
Я, может быть, не поленюсь все же собрать что-то работающее через неделю-другую, если не забуду. Просто ради интереса. Но не думаю, что проделаю подобное с каким-то рабочим проектом, кроме как ради job safety.
как-то я лажанулся.
мне казалось, он не только truncation в parse transform делает, но и лишние loglevel-ы режет. сейчас проверил — и вправду не режет.
> компиляция модуля на лету
он генерил модуль-dispatcher на основе конфигурации? если да, всецело одобряю.
вообще, на эту тему нужно поиграться с merl, но осторожно, чтобы не увлечься.
кстати, если я все правильно понимаю, протоколы elixir в develop mode работают так же.
Для справедивости отмечу, что «отладочный логгер, который в продакшн версии просто отсутствует» есть в lager уже очень давно без всяких макросов, на голом parse transform. В принципе, parse transform по функциональности недалеко ушли от макросов, просто менее удобны в использовании.
BTW, я считаю лисп хорошим, правильным, годным языком. Если хочешь нормальные макросы, тебе нужен лисп. Опять же, современный лисп может быть очень хорош и удобен, как показывает clojure.
Немного про макросы elixir и parse transform от Роберта Вирдинга, автора lfe — https://news.ycombinator.com/item?id=7623991
> Дисковый бэкенд недавно реализованный в KVS
Он на DETS, DETS — плохой. У него время восстановления после некорректного закрытия растет как бы не экспоненциально от размера таблицы. Как следствие, и mnesia не очень. Были какие-то попытки в нее вкорячить leveldb в качестве дискового бэкэнда, я не знаю их текущий статус.
> WhatsApp
Они как-то умеют ее готовить.
> Observer с подключением к удаленной ноде
Это вместо человеческого консольного клиента? Ну нет, все же не то. Опять же, это требует сильно больше знаний, чем есть у некого рандомного веб-разработчика.
С конфигами это отдельная больная тема. Вообще, хранить в файле конфигурации сырой снапшот внутреннего представления, как это делается в каноничном app.config — это какой-то кромешный ужас.
Не, я понимаю, откуда оно взялось такое решение, но на сегодняшний день это не выглядит пригодным к широкому использованию.
Ну, на мой вкус это уже чересчур радикально — впрочем, твоя разработка, тебе виднее.
У меня просто прибиты коммиты или теги в ребаре, мне так нормально.
Будем честны — ну все и не везде так просто, даже если забыть про парсинг JSON.
Продолжая быть честными — да, в эрланге очень не хватает какого-то рантайм-полиморфизма и dynamic dispatch. Но чего нет, того нет, и как это вообще впилить в имеющийся рантайм, ничего не потеряв — неясно.
У меня все просто, слизано с flussonic Макса Лапшина( erlyvideo ). Релизы не используются. Версии подкладывает rebar_vsn_plugin из тегов git. Сборка — rebar + make. В мейкфайле руками прописана некоторая часть зависимостей, типа app: lager_parse_transform_beam, для удобства.
На продакшн код попадает в deb-е, в котором file layout не отличается от версии разработчика, как оно лежит в git, но все уже заранее скомпилировано. У deb-а прописаны dependencies от esl-erlang и пакетов, требуемых для нативного кода — портов, nif, каких-то скриптов. В postinst-скрипте деба делается какая-то конфигурация — пользователь, права на директории.
Запускается приложение через run_erl под upstart — вот это на самом деле очень сложный в отладке момент, по возможности копируется из другого проекта. =)
Запуск — есть модуль с функцией start/0, в ней мы читаем конфиг — свой, не sys.config, если он плохой — валимся с каким-то вменяемым сообщением об ошибке. На основе этого своего конфига генерятся в коде конфиги приложений, от которых зависим — lager, jobs, свои приложения, кладутся в application env соответственные. В конце start запускаются otp приложения, по возможности через application:ensure_all_started(my_app) и дергается my_app:apply_config, который уже раскидает отдельные элементы env-а по подсистемам, говоря им «вот новый конфиг, примени его к себе». Да, со структурой supervision tree могут быть некоторые неудобства, но я с ними не сталкивался, у меня эта структура достаточно фиксированная.
Если очень хочется, вместо нормальной файловой структуры можно запилит один большой escript со всеми модулями и автораспаковкой прочих файлов в /tmp, но я от этого отказался — совсем уж убивает удобства от hot reload, когда хочется/нужно на скорую руку что-то поправить. В принципе, это можно попробовать делать ради самодисциплины, чтобы руки не тянулись патчить продакшн на горячую.
Флаги эмулятора типа +sbt или -name у меня захардкожены в точке запуска, но есть и варианты получше — vm.args, какой-то другой конфиг, unix env.
Много инстансов одного приложения на одной системе поднимать мне не приходилось, готовых вариантов пока нет.
Обязательно в пакете shell-скрипт, который сделает remsh в ноду приложения.
Проблем с множественными epmd у меня не было; в случае возникновения можно отдельным дебом ставить eclus — это версия epmd на go без зависимостей, и поднимать его upstart-ом до первого erlang-сервиса. По меньшей мере, как-то так мне это видится, я пока не пробовал.
Докера в продакшне у меня пока нет; в теории там могут возникнуть какие-то нюансы, типа коллизий имен нод, я их еще не продумывал. В остальном все примерно так же, либо берем докер-образ с апстартом внутри, либо просто корнем контейнера запускаем наш враппер над run_erl erl…
Да, это все абсолютная ересь по меркам «каноничной» erlang-разработки, но меня вполне устраивает.
А еще есть C#, который тоже сильно проще С++, а .NET есть на каждой винде.
> не нужно никому 200 долларов отдавать
Хорошая шутка. Welcome отлаживать код на C++/GStreamer и опционально код браузера, расскажете только потом, что было ли это дешевле и проще, чем заплатить людям, которые сделают это за вас.
Вообще, в плане WebRTC надежды не вселяет вообще ничто.
Да ну, так никто не делает. Это мягко говоря неоптимально, да и не нужно никому.
Однако, по стандарту WebRTC видео действительно кодируется для каждого клиента персонально. Типа для QOS. Еще одна причина сказать, что WebRTC не очень.
200$ у VoxImplant стоит поддержка. На все остальное у них, я бы сказал, терпимые цены.
Для примера, на наши вебинары(не буду уточнять), разработку+хостинг, у нас уходит 200+к руб/месяц. Цены на закупки железа так и вообще вгоняют в ужас. И это не самый посещаемый проект и не в стадии активной разработки.
Есть P2P-WebRTC, есть несколько open-source реализаций релейных серверов для WebRTC. Масса геморроя, сложно масштабируется.
Есть VoxImplant, действительно — и должен быть удобнее голого WebRTC. Но вы заплатите за весь гемор из предыдущего пункта и еще чуть сверху на развитие. =)
А Wowza — хороший мультипротокольный стриминг-сервер, но совсем не про то.
Ну и вообще, они все про архитектуру рантайма Go, которая за прошедший год сильно не менялась.
В принципе, все.
Есть эрланг-проект, собирается ребаром, основным является именно он. На эликсире только прослойка для работы с БД с ecto — абсолютно нормальные требования, на мой взгляд.
Тем более, что ecto — единственная причина вообще заморачиваться.
А дальше начинается ожидаемое. rebar_elixir_plugin не умеет в app-файлы в принципе. ecto из ребара не собирается. То есть, ради использования одной библиотеки мне нужно менять систему сборки проекта. Приехали.
Уже на этом этапе можно закрывать тему, но немного заглянув вперед, мы узнаем, что на каждый чих нужно писать враппер-функцию erlang map -> ecto struct. А то и erlang record -> ecto struct. Что ecto жестко привязан к эликсирному логгеру, как результат нам нужно конфигурить два логгера при старте — потому что у нас уже есть логгер, какой проект без логгера.
Да, я не умею готовить эликсир. Но мне не кажется, что интеграция с хостовым языком должна выглядеть так.
Я, может быть, не поленюсь все же собрать что-то работающее через неделю-другую, если не забуду. Просто ради интереса. Но не думаю, что проделаю подобное с каким-то рабочим проектом, кроме как ради job safety.
мне казалось, он не только truncation в parse transform делает, но и лишние loglevel-ы режет. сейчас проверил — и вправду не режет.
> компиляция модуля на лету
он генерил модуль-dispatcher на основе конфигурации? если да, всецело одобряю.
вообще, на эту тему нужно поиграться с merl, но осторожно, чтобы не увлечься.
кстати, если я все правильно понимаю, протоколы elixir в develop mode работают так же.
BTW, я считаю лисп хорошим, правильным, годным языком. Если хочешь нормальные макросы, тебе нужен лисп. Опять же, современный лисп может быть очень хорош и удобен, как показывает clojure.
Немного про макросы elixir и parse transform от Роберта Вирдинга, автора lfe — https://news.ycombinator.com/item?id=7623991
Он на DETS, DETS — плохой. У него время восстановления после некорректного закрытия растет как бы не экспоненциально от размера таблицы. Как следствие, и mnesia не очень. Были какие-то попытки в нее вкорячить leveldb в качестве дискового бэкэнда, я не знаю их текущий статус.
> WhatsApp
Они как-то умеют ее готовить.
> Observer с подключением к удаленной ноде
Это вместо человеческого консольного клиента? Ну нет, все же не то. Опять же, это требует сильно больше знаний, чем есть у некого рандомного веб-разработчика.
Разница между Python и Go в рантайме. Multicore green thread scheduler решает. Это строго преимущество.
Везло мне, чтоли.
Не, я понимаю, откуда оно взялось такое решение, но на сегодняшний день это не выглядит пригодным к широкому использованию.
У меня просто прибиты коммиты или теги в ребаре, мне так нормально.
Продолжая быть честными — да, в эрланге очень не хватает какого-то рантайм-полиморфизма и dynamic dispatch. Но чего нет, того нет, и как это вообще впилить в имеющийся рантайм, ничего не потеряв — неясно.
На продакшн код попадает в deb-е, в котором file layout не отличается от версии разработчика, как оно лежит в git, но все уже заранее скомпилировано. У deb-а прописаны dependencies от esl-erlang и пакетов, требуемых для нативного кода — портов, nif, каких-то скриптов. В postinst-скрипте деба делается какая-то конфигурация — пользователь, права на директории.
Запускается приложение через run_erl под upstart — вот это на самом деле очень сложный в отладке момент, по возможности копируется из другого проекта. =)
Запуск — есть модуль с функцией start/0, в ней мы читаем конфиг — свой, не sys.config, если он плохой — валимся с каким-то вменяемым сообщением об ошибке. На основе этого своего конфига генерятся в коде конфиги приложений, от которых зависим — lager, jobs, свои приложения, кладутся в application env соответственные. В конце start запускаются otp приложения, по возможности через application:ensure_all_started(my_app) и дергается my_app:apply_config, который уже раскидает отдельные элементы env-а по подсистемам, говоря им «вот новый конфиг, примени его к себе». Да, со структурой supervision tree могут быть некоторые неудобства, но я с ними не сталкивался, у меня эта структура достаточно фиксированная.
Если очень хочется, вместо нормальной файловой структуры можно запилит один большой escript со всеми модулями и автораспаковкой прочих файлов в /tmp, но я от этого отказался — совсем уж убивает удобства от hot reload, когда хочется/нужно на скорую руку что-то поправить. В принципе, это можно попробовать делать ради самодисциплины, чтобы руки не тянулись патчить продакшн на горячую.
Флаги эмулятора типа +sbt или -name у меня захардкожены в точке запуска, но есть и варианты получше — vm.args, какой-то другой конфиг, unix env.
Много инстансов одного приложения на одной системе поднимать мне не приходилось, готовых вариантов пока нет.
Обязательно в пакете shell-скрипт, который сделает remsh в ноду приложения.
Проблем с множественными epmd у меня не было; в случае возникновения можно отдельным дебом ставить eclus — это версия epmd на go без зависимостей, и поднимать его upstart-ом до первого erlang-сервиса. По меньшей мере, как-то так мне это видится, я пока не пробовал.
Докера в продакшне у меня пока нет; в теории там могут возникнуть какие-то нюансы, типа коллизий имен нод, я их еще не продумывал. В остальном все примерно так же, либо берем докер-образ с апстартом внутри, либо просто корнем контейнера запускаем наш враппер над run_erl erl…
Да, это все абсолютная ересь по меркам «каноничной» erlang-разработки, но меня вполне устраивает.