Пережимаем с помощью ffmpeg в размер навроде 160x120 и можно также с маленьким битрейтом, а потом при желании можно и увеличить размер кадра - качество всё равно уже будет утеряно. Самый простой способ.
The_one_who_asks, именно поэтому шарить лучше просто некий общий каталог на всё, а создавать уже внутри него. И обычно именно так и делают.
Правда, возникнет вопрос с правами доступа, если нужны кастомные. Ну там есть два соображения: с одной стороны, каждому отделу/департаменту/рабочей группе делается своя шара (а отделы не появляются каждый день), с другой - можно правами внутри сервера разделять доступ по группам даже в пределах одной шары.
Я даже накручивал acl. Например, есть личные каталоги учеников в школе, доступные только им лично (как бы у любого юзера есть такой), и есть шара, через которую учитель их видит все разом и имеет доступ к ним, в том числе на запись. Учителя, соответственно, входят в одну группу, которая используется в дополнительном acl на все каталоги учеников.
Это легальный WhatsApp Business API или нелегальная имитиация Web API? Легальный у некоторых провайдеров фактически пробрасывает как есть запросы в WA (только авторизация подменяется), и в нём в POST явно не такое надо посылать, а в GET ничего подобного не передаётся.
Более того, если компы в домене, то можно ещё и соорудить автоматическое подключение как сетевого диска через вызовы net use в logon script. Я в своё время делал чтобы файлопомойка автоматически у всех подключалась например как S:\
Если бы у smb-ссылок в винде был нормальный спосол использования через URI, как в Linux через smb://, то было бы проще - можно было бы давать ссылки, например, во внутреннем вики или в письмах.
Neitr, у нас был Slack, пока в нём сидела разработка, эксплуатация и саппорт, было ещё более-менее по цене, когда решили внедрить во всю компанию поняли что ценник негуманный, и тогда выбрали Rocket.Chat за то что он достаточно близок к слаку по идеологии. Но он оказался довольно глючным и тормозным, поэтому в прошлом году изучали альтернативы, в шортлист вошли Mattermost и Matrix, в итоге победил Matrix и мы провели тест его использования, по итогу руководство того отдела, что вело этот проект, решило остаться на Rocket.Chat и просто его немного доработать (своя сборка мобильного приложения, свой модуль интеграции с LDAP).
По поводу Rocket.Chat есть такие проблемы:
1. В мобильном клиенте есть недостаточно поддерживаемые фичи, из-за чего сообщения с кусками кода временами рендерятся криво.
2. Мобильный клюент в бесплатной версии глючит с пушами, часто пуши опаздывают, иногда приходят прям пачками и даже дублируются. Можно заплатить разрабам за поддержку, и пуши будут идти через другой сервер и работать быстрее, но всё равно не очень надёжно. Мы в итоге сделали свою сборку клиента со своими пушами, но её приходится ставить не из сторов, на андроиде ещё ничего, на яблоках это какой-то странный квест...
3. Декстопная версия очень любит жрать память и вообще не очень отзывчива по скорости работы. Вообще, кто-то у нас заметил, что там в интерфейсе дофига избыточных div и span...
4. Это приложение на Electron, причём один из худших вариантов, которые я встречал. Да, я знаю, что приложения на Electron это фактически браузер, но всё же. Вон, клиент Matrix Element тоже Electron, но он реально клёво написан, память не жрёт, работает быстро и красиво.
В общем-то мы привыкли, да и глючить оно стало в современных версиях чуть меньше, чем раньше, хоть и жаль, что прогресс такой медленный.
Также смотрели Mattermost. Его декстопный клиент вроде выглядел поприличнее Rocket.Chat, но он кажется чуть меньше похож на Slack. Про мобильный клиент не помню впечатления.
Ещё смотрели Zulip, это довольно забавная штука, там можно текстовые топики создавать прям в канале и фильтровать по ним, этакая замена тредов, но это явно будет пользователям тяжело воспринимать.
Что касается аудиовидео, большинство открытых проектов такого рода просто используют Jitsi Meet, позволяя прям из клиента создать в нём встречу и показывая в webview её. Можно поставить свой сервер Jitsi Meet и использовать. У нас всё равно свой сервер есть, мы его и внутри используем, и для встреч с внешними пользователями (включая онлайн-собеседования). Правда, часть сотрудников всё равно используют обычный Zoom с личными аккаунтами :)
lolrofl01, никак, докер даёт приложению очень мало времени на завершение, потом убивает принудительно, с высокой вероятностью никакие потуги не позволят гарантированно записать базу в файл.
Вообще, советую пересмотреть свою задачу: зачем ей вообще нужны такие манипуляции? Может, нужно базу в докер не засовывать, а запустить на хосте?
Neitr, да, может. И даже его функции федерации можно зарезать, чтобы нельзя было связываться с другими Matrix-серверами.
Но есть некоторые неудобства в том, что пользователей придётся обучить его функциям криптографии (бэкап ключа, авторизация других устройств итд). Это стало основным препятствием, почему у нас в конторе решили его не внедрять.
Не надо копипастить простыню кода безо всяких пояснений. Может, автор вопроса скопипастит и у него заработает (но не факт), а вот понимания не прибавится и лучше программировать он не научится.
Вадим, интернет там был ни при чём. Браузер тормозит - скрипт считает, что видео отдаётся медленно - понижает качество.
Ну а общее соображение в том, что "интернет хороший" - это масло маслянное. Как будет роутиться трафик и какая будет загруженность конечного сервера угадать никогда нельзя. Тем более что, как я говорил, у них может быть такой же автодетект, как у ютуба и других хостингов, который снизит качество при любых лагах сети.
EDIsaev, раньше были деятели которые сканили номера телефонов перебором, потом Телеграм это прикрыл. В общем-то если на сайте бронируют одну из четырёх комнат в доме, то вряд ли это страшно, а если это что-то более сурьёзное, то я бы уже поостерёгся.
Этот функционал НЕ ПРЕДНАЗНАЧАЛСЯ для отправки сообщений автоматизированно неограниченному кругу пользователей, он нужен только для работы полноценных Телеграм-клиентов.
habrdima, в реальности объект requests.Session - это не коннект. Это что-то типа "шаблона запроса", который может иметь параметры по умолчанию, запоминать полученные от сервера куки итд итп. Можно с одной сессией запросить сначала яндекс, потом гугл, и это не будет значить, что будет один коннект.
Более того, изначально дизайн протокола HTTP предполагал, что по одному коннекту может пройти только один запрос. Потом появился HTTP/1.1 с keepalive, где можно держать коннект и гонять по нему несколько запросов. Но ни один сервер в здравом уме не будет держать часами коннект, по которому нет никакой активности. Поэтому в реальности коннект не будет удерживаться вечно, он всё равно закроется и достаточно быстро.
Тем более что нормальный способ использования requests.Session - не создавать сессию с нуля в тысячах функций, а создать один раз и использовать повсеместно.
