Представлен (https://blog.zulip.org/2018/11/07/zulip-1-9-released/) релиз Zulip 1.9 (https://www.zulip.org), серверной платформы для развёртывания корпоративных мессенджеров, подходящих для организации общения сотрудников и групп разработчиков. Проект изначально был разработан компанией Zulip и открыт после её поглощения компанией Dropbox под лицензией Apache 2.0. Код серверной части написан (https://github.com/zulip/zulip) на языке Python с использованием фреймворка Django. Клиентское ПО доступно (https://github.com/zulip/zulip-electron) для Linux, Windows, macOS, Android (https://github.com/zulip/zulip-android) и iOS (https://github.com/zulip/zulip-mobile), также предоставляется встроенный web-интерфейс.
Система поддерживает как прямой обмен сообщениями между двумя людьми, так и проведение групповых обсуждений. Zulip можно сравнить с сервисом Slack (https://ru.wikipedia.org/wiki/Slack) и рассматривать как внутрикорпоративный аналог Twitter, применяемый для общения и обсуждений рабочих вопросов в больших группах сотрудников. Предоставляются средства для отслеживания состояния и участия одновременно в нескольких обсуждениях с использованием нитевидной модели отображения сообщений, которая является оптимальным компромиссом между привязкой к комнатам в Slack и единым публичным пространством Twitter. Одновременное нитевидное отображение всех обсуждений позволяет в одном месте охватить все группы, при этом сохранив логическое разделение между ними.
Из возможностей Zulip также можно отметить поддержку отправки сообщений пользователю в offline-режиме (сообщения будут доставлены после появления в online), сохранение полной истории обсуждений на сервере и средства для поиска в архиве, возможность отправки файлов в режиме Drag-and-drop, aвтоматическую подсветку синтаксиса для передаваемых в сообщениях блоков кода, встроенный язык разметки для быстрого оформления списков и форматирования текста, средства для групповой отправки уведомлений, возможность создания закрытых групп, интеграция с Trac, Nagios, Github, Jenkins, Git, Subversion, JIRA, Puppet, RSS, Twitter и другими сервисами, средства для привязки к сообщениям наглядных меток.Основные новшества (https://zulip.readthedocs.io/en/latest/overview/changelog.html):
- Реализованы инструменты для импорта данных из HipChat и Gitter. Завершено бета-тестирование модуля для импорта из Slack;
- Запуск Python-процесса Zulip ускорен приблизительно на 30% благодаря решению проблем с производительностью в django-bitfield, libthumbor и pika;
- Добавлена возможность создания собственных полей в профиле, позволяющих размещать специфичную для каждой организации информацию о сотрудниках;
- Добавлена поддержка использования Google Hangouts вместо Jitsi для обеспечения работы видеочата;
- Пользователям предоставлена возможность настройки push-уведомлений или уведомлений по email;
- Добавлены настройки, позволяющие контролировать доступ пользователей к истории приватных каналов до подключения к каналу, а также возможность создания каналов, в которые имеют право отправлять сообщения только администраторы;
- Представлена экспериментальная поддержка предоставления доступа к каналам неавторизированных гостей, например, при необходимости просмотра определённых каналов подрядчиками;- Реализованы новые модули для бесшовной интеграции с Ansible Tower, Appveyor, Clubhouse, Netlify и Zabbix;
- Добавлена поддержка Ubuntu 18.04 и Debian 9.URL: https://blog.zulip.org/2018/11/07/zulip-1-9-released/
Новость: https://www.opennet.ru/opennews/art.shtml?num=49573
> Код серверной части написан на языке Python с использованием фреймворка DjangoЗначит не тормозит и уязвимостям не подвержен. И с параллелизмом. И легко сопровождаем. Очевидный выбор любого здравомыслящего (и толерантного) человека.
> С параллелизмомПодразумеваю CPython как основную целевую реализацию Python. CPython имеет только гринлеты.
> Python с использованием фреймворка Djangoраз уж сказали в морг, значит в морг..... Пора уже этот ужас забыть....
какой кошмар, твои страданья, стереть нельзя воспоминанье!ты еще лет сорок будешь обслуживать эти помойки. А потом сдохнешь.
У питонистов даже пара лет вызывает устойчивые проблемы совместимости. За 40 лет оно разложится без каких-либо воспоминаний.
Не зулипает
> Из возможностей Zulip также можно отметить поддержку отправки сообщений пользователю в offline-режиме (сообщения будут доставлены после появления в online)Неужели где-то этого нет?
> Представлен релиз Zulip 1.9, серверной платформы
> Код серверной части
> Из возможностей Zulip также можно отметить поддержку отправки сообщений пользователю в offline-режимеОбычно, это подчёркивают только в распределённых безсерверных мессенджерах, где это действительно нетривиальная задача.
Серьезно? Сохранить сообщение в LocalStorage и достать оттуда после выхода в Online и прицепа через WebRTC к другой ноде?
> Сохранить сообщение в LocalStorageчей?
> и достать оттуда после выхода в Online
кого?
весь прикол в том, что в распределенной системе может случиться и так, что ты и тот,кому ты написал, в онлайне одновременно не бывают (или бывают слишком редко, когда сообщение уже потеряет смысл)
и кого это должно волновать?
сообщение отправлено, значит должно быть доставлено, когда получатель будет в сети, и это ни его (получателя), ни моя (отправителя) проблема, что мы оба не бываем одновременно "в сети". временное хранилище на стороне сервера должно быть, история же куда-то сохраняется.
для меня вопрос о нетривиальности открыт - что там нетривиального?
>> в распределённых безсерверных мессенджерах,
> временное хранилище на стороне сервера должно быть,А ты сообразительный.
> временное хранилище на стороне сервера должно быть, история же куда-то сохраняется.А вы слуачем не работаете в майкрасофте в скайп отделе?
>>временное хранилище на стороне сервера должно бытьв бессерверной архитектуре то самое "временное хранилище" на стороне отправителя ДОЛЖНО БЫТЬ.
>>кому ты написал, в онлайне одновременно не бываютпользуйтесь голубиной почтой, нафига использовать мессенджеры "мгновенных" сообщений если ты используешь его раз в месяц?
>>>кому ты написал, в онлайне одновременно не бывают
> пользуйтесь голубиной почтой, нафига использовать мессенджеры "мгновенных" сообщенийголубь-то поумнее будет - даже если голубятня закрыта, будет болтаться рядом с ней, пока владелец не проснется и не впустит, питаясь чем бабка послала. (правда, в процессе его может сожрать кошка)
> если ты используешь его раз в месяц?
разные часовые пояса, платный траффик - не, не слышал?
>>не, не слышал?а про разницу "мгновенно" и "через месяц" - не слышал?
>>будет болтаться рядом с ней
а вот тут вопрос к голубятникам, как по мне, он вернётся обратно если его не приняли, и никого он ждать не будет.
"он вернётся обратно если его не приняли" — спасибо, улыбнуло.
Прямо представил себе такого вот голубя, которому некто (менеджер по голубям ?) выдаёт полётное задание.
> "он вернётся обратно если его не приняли" — спасибо, улыбнуло.
> Прямо представил себе такого вот голубя, которому некто (менеджер по голубям ?)
> выдаёт полётное задание.таки да, а если в серьез, то голубями обменивались, чтобы они возвращались домой, а не летели хрен знает куда.
> чей?Чьём?
> весь прикол в том, что в распределенной системе может случиться и так,
> что ты и тот,кому ты написал, в онлайне одновременно не бывают
> (или бывают слишком редко, когда сообщение уже потеряет смысл)Поэтому есть ноды-посредники, например ваши друзья.
Ваше сообщение шифруется ключом получателя и рассылается друзьям, которые могут передать сообщение адресату, когда тот появится в сети.По-сути все эти новомодные штуки работают по принципу торрента с той лишь разницей, что они шлют зашифрованные сообщения и вместо центрального трекера используется DHT либо альтернативные протоколы.
Основной недостаток распределенных систем заключается в том, что для поддержании работы сети нужны дополнительные расходы ресурсов клиентов. Поэтому же устойчивость сети полностью зависит от количества узлов в ней.
В сети могут существовать кластеры, которые обеспечивают промежуточное сохранение сообщений. Эти сервера выполняют роль перевалочных баз. Они знают только координаты узла получателя и узла отправителя. В принципе так работают системы маршрутизации, которые инкапуслируют содержимое пакета и шлют его дальше по магистрали.
Вариаций данного принципа много. Надеюсь, я приоткрыл для вас мир распределенных систем. Рекомендую погуглить про distributed web. И не обсирать других только потому, что у вас ЧСВ зашкаливает.
> Поэтому есть ноды-посредники, например ваши друзья."не друзья они мне, Машенька, больше!"
> Ваше сообщение шифруется ключом получателя и рассылается друзьям, которые могут передать
> сообщение адресату, когда тот появится в сети.может случиться, что это не эффективнее прямого подключения - по тем же причинам, по которым не работает и прямое. Поэтому идея да, верная, но использовать мы будем компьютеры не-друзей.
> Основной недостаток распределенных систем заключается в том, что для поддержании работы
> сети нужны дополнительные расходы ресурсов клиентов. Поэтому же устойчивость сети полностьюда кто ж их спрашивает-то ;-)
Что нетривиального? Написал, мессенджер (если бессерверный то сам клиент) ждёт в фоновом режиме когда адресат появится и отправляет.
Написал, выключил ноутбук...а мессенджер "ждёт в фоновом режиме когда адресат появится и отправляет".
Здорово блин.. действительно. Чертовски здорово... Придумано... осталось реализовать...
Десктопный клиент может передать сообщение на смартфон ни поручить эту задачу мобильному клиенту, смартфоны-то мало кто часто выключает.
>>Написал, выключил ноутбук..специально для людей с такой логикой, выше коментом описал - пользуйтесь голубиной почтой, мессенджер "мгновенных" сообщений не для вас.
Это же идиотизм.
Сообщения должны доставляться независимо от наличия связи на том конце. То есть, если сообщение может не придти при включении онлайне, то такая система должна умереть.
Как только ей можно доверять, если сообщения не дойдут?
Да лучше я буду голубиной почтой пользоваться, я там знаю риски,а тут Спортлото. Сами играйте у рулетку.
> Это же идиотизм.
> Сообщения должны доставляться независимо от наличия связи на том конце.)))))) инопланетяне ржут с твоего коммента.
>>то такая система должна умереть.система "мгновенности", должна жить тогда и только тогда, когда оба конца "в онлайне" - точка.
если у вас ситема не живет по таким правилам (понятиям, протоколам), то это не "мгновенная" система, как указал выше - пользуйтесь голубиной почтой.>>Как только ей можно доверять, если сообщения не дойдут?
Так же как мы доверяем транспортам tcp и udp.
>>Да лучше я буду голубиной почтой пользоваться
ну наконец то дошло до вас, и поняли в чём разница между "мгновенно", и "через месяц".
>>Сами играйте у рулетку.
жизнь игра, а мы в ней игроки, и у каждого свои правила на неё.
Skype 4 Business от МС, как пример - нет оффлайн доставки сообщений ...
Есть, но они падают в почту, в missed conversations
это в актуальной на сегодня версии 16.0 они попадают xD
> это в актуальной на сегодня версии 16.0 они попадают xDчёт нифига в 16.0.4738.x нифига не приходит ни на почту ни в скайп если слать в оффлайн
"ФИО в настоящий момент не может получать сообщения, т. к. установлен статус "Недоступен" или "Не в сети"."
и никакой почты не бывает после
> Есть, но они падают в почту, в missed conversationsэто, кажись, только при интеграции с exchange. (в смысле, эта почта ни разу не smtp)
Это они политкорректные леваки или я с кем-то их путаю?
Чем это лучше matrix-synapse + riot?
Есть два стула...
эмм ребята решили сделать свой велосипед?
джаббер не устраивает?
Это скорее для тех, кого не устраивает Slack. Будет ещё один "убийца" в списке.
долой слак, даешь человеческий IRC!
> долой слак, даешь человеческий IRC!Надо просто сделать морду к IRC, решающую те же задачи (красиво и для тупых) и не вижу причин для существования Слака.
В джабере много лишнего
проблема не в лишнем, это можно бы потерпеть. проблема в том, что множества XEP-ов в клиентах и серверах как-то хитро пересекаются. и граждане, которые что-то хотят на xmpp идут вот так:
- о! я нашёл XEP, он нужен, почему его никто не использует!?
- ой, а что оно не везде работает...
- ой, а давайте напишем свой клиент...
- и сервер...
- и не на xmpp...
А почему бы патчей не заслать вместо написания с нуля?
> А почему бы патчей не заслать вместо написания с нуля?Патчи на ерланг, например, могут не только лишь все.
А что, кто-то ставит ejabberd вместо prosody?
Я пошел по ссылкам и посмотрел фичи, первое что увидел что можно вставлять код с подсветкой синтаксиса, LaTeX, и автоматическое подхватывание ссылок на баги. А jabber просто месенджер. По этой причине этот zulip может быть очень годен в распределенной команде.
> Я пошел по ссылкам и посмотрел фичи, первое что увидел что можно
> вставлять код с подсветкой синтаксиса, LaTeX, и автоматическое подхватывание ссылок на
> баги. А jabber просто месенджер. По этой причине этот zulip может
> быть очень годен в распределенной команде.вы идиот?
"можно вставлять код с подсветкой синтаксиса, LaTeX, и автоматическое подхватывание ссылок на баги. А jabber просто месенджер."
вы описали функционал показа сообщения клиентом, а не функционал jabber-а
Утверждаешь jabber это не клиенты, жабер это протокол? Ну давай... найди мне клиент который сможет LaTeX, подсветку кода, урлы на тикеты, я помню сколько мы клиентов jabber'а перебрали только чтоб аудиосвязь у всех работала работала. Также фигна с SIP, но это уже совсем другая история...
> Утверждаешь jabber это не клиенты, жабер это протокол? Ну давай... найди мне
> клиент который сможет LaTeX, подсветку кода, урлы на тикеты, я помню
> сколько мы клиентов jabber'а перебрали только чтоб аудиосвязь у всех работала
> работала. Также фигна с SIP, но это уже совсем другая история...статья 2009 года указывает минимум 3 клиента с поддержкой LaTeX https://habr.com/post/50776/
в том числе православная мирандочка
миранда - клиент
жаббер - протокол
один клиент поддерживает множество протоколов, в том числе богомерзкие протоколы скайпа и вконтактика
и способен передавать и показывать LaTeX сквозь любой из этих протоколов
> можно вставлять код с подсветкой синтаксиса, LaTeX, и автоматическое подхватывание ссылок на багиПочему нельзя то же самое запилить в IRC на стороне клиента?
Джаббер, как сын своей эпохи ICQ, в новых реалиях плохо применим. Людям не нужен обособленный клиент с навороченной логикой, людям нужен легкий веб-интерфейс со всеми удобствами на месте, вне зависимости от реализации клиента.
И главное — у всех одинаковый.
вебинтерфейс в телефоне это редкостное неудобство.
для zulip есть мобильные клиенты
Тогда причём тут веб-интерфейс?
и гигабайты ОЗУ этим легким веб-клиентам. спасибо, а то мы на нативных qt/gtk сидели, а теперь вот апрейдить комп нужно чтобы он текст отправлять мог.
> легкий веб-интерфейсЛибо лёгкий, либо вэб-интерфейс.
Напоминает мою старинную идею живого форума, которую я пилю в свободное время.
Ну, показывай.
> Ну, показывай.Да стыдно пока показывать. Если очень хочется посмотреть на прототип, то он запущен тут linuxquestions.ru (сырой).
Гипертекстовый фидонет?
> Гипертекстовый фидонет?Да
сколько памяти потребляет серверная часть?
И снова desktop-клиент на ущербном электроне...
Тогда лучше в Фонд Apache.
в данном случае в desktop клиенте смысла практически нет, все тоже самое, что в веб интерфейсе
Блин, они бы название сменили... Абсолютно невозможно это кому-то предлагать...
Кто-нибудь сравнивал Zulip с Mattermost? https://www.mattermost.org/
Вот тут немного автор сравнивает https://serveradmin.ru/ustanovka-i-nastroyka-zulip/
Есть статьи и по зулипу и по маттермосту, можно ознакомиться.
> Кто-нибудь сравнивал Zulip с Mattermost? https://www.mattermost.org/Сравнивали, выбрали Rocketchat
rocketchat показался сырым и глючным, мы выбрали zulip
Требования у него большие. CPU and Memory: For installations with 100+ users you’ll need a minimum of 2 CPUs and 4GB RAM. For installations with fewer users, 1 CPU and 2GB RAM is sufficient. We strongly recommend against installing with less than 2GB of RAM, as you will likely experience out of memory issues installing dependencies. We recommend against using highly CPU-limited servers like the AWS t2 style instances for organizations with a hundreds of users (active or no).Disk space: You’ll need at least 10GB of free disk space for a server with dozens of users. If you intend to store uploaded files locally rather than on S3 you will likely need more, depending how often your users upload large files. You’ll eventually need 100GB or more if you have thousands of active users or millions of total messages sent.
один раз задеплоил это zulip, посмотрел на процесс-результат, снес
Все бы мне в нем хорошо если бы не electron https://github.com/zulip/zulip-electron
0.5G ореративы не понятно куда.
Без майора?
Это недоработка, надо срочно принять закон.
>Python с использованием фреймворка Django.Нет, спасибо.
ну а че, снова на ноде писать?
//offtop
подскажите, пожалуйста, децентрализованную систему для чатов (безсерверную) с клиентами на винде и линуксе с возможностью:
1) подтягивать историю чата от других пользователей
2) автоподключение к чату при логине
2) пересоздание чата на лету после того как все пользователи её покинули и кто-то запустил чатилку
3) желательно: экспорт истории в файл
А если охота аля джаббер (локальный сервер), но чтобы файлы можно было кидать и из инета кто-то заходить мог секюрно, ну и чат программу в трее, а не в браузере?
Так поднимите локальный сервер джаббера (Openfire) и выставите его по айпишнику в инет. Клиент в трее — Pidgin. В чём проблема-то? Секьюрность есть, файлы кидаются.
и виснет всего лишь пару раз в день, а жрет пол-терабайта оперативки непойми на что.нет, спасибо - именно по этой причине в свое время пришлось уходить на ejabberd (который тоже, конечно, та еще субстанция)