Comments 67
Это называется открытая платформа github.com/actorapp/actor-js/blob/master/actor.nocache.js?
И можно много много вопросов к вашему фронтенду, github.com/actorapp/actor-js-old. Чем был аргументирован выбор coffescript?
Почему не использовали AMD, CommonJS, es2015 (requirejs, browserify, webpack/requirejs)?
Игде когда же можно посмотреть исходники веб версии?
PS: выглядит очень интересно и даже очень очень.
И можно много много вопросов к вашему фронтенду, github.com/actorapp/actor-js-old. Чем был аргументирован выбор coffescript?
Почему не использовали AMD, CommonJS, es2015 (requirejs, browserify, webpack/requirejs)?
И
PS: выглядит очень интересно и даже очень очень.
Это называется открытая платформа github.com/actorapp/actor-js/blob/master/actor.nocache.js?
И можно много много вопросов к вашему фронтенду, github.com/actorapp/actor-js-old. Чем был аргументирован выбор coffescript?
actor-js и actor-js-old – устаревшие репозитории. Все актуальные исходники лежат в github.com/actorapp/actor-platform.
Почему не использовали AMD, CommonJS, es2015 (requirejs, browserify, webpack/requirejs)?
Весь фронтенд написан на ReactJS, Flux собирается с использованием Webpack.
И где когда же можно посмотреть исходники веб версии?
github.com/actorapp/actor-platform/tree/master/actor-apps/app-web
brainsmith спасибо!
Весь фронтенд написан на ReactJS, Flux собирается с использованием Webpack.Вот другое дело, есть где подсмотреть бестпрактис что собственно и хотел с самого начала :)
Весь фронтенд написан на ReactJS
В документации написано Angular, кому верить?
actor.readme.io/docs/apps#section-web
del
У вас есть аудио/видео звонки?
Я продолжу задавать вопросы если это вас не раздражает.
Почему выбрали sass о переходе на bem и postcss думали?
Не страшно использовать context с react 0.13.3 ведь context обещали только после 0.14?
Почему не использовали flexbox ведь у вас автопрефиксер на последние три версии браузеров?
Зачем использовали свой css grid, а не взяли существующий?
PS: Простите, простите, мне правда очень интересно :)
Почему выбрали sass о переходе на bem и postcss думали?
Не страшно использовать context с react 0.13.3 ведь context обещали только после 0.14?
Почему не использовали flexbox ведь у вас автопрефиксер на последние три версии браузеров?
Зачем использовали свой css grid, а не взяли существующий?
PS: Простите, простите, мне правда очень интересно :)
Почему выбрали sass о переходе на bem и postcss думали?
С sass, так сложилось исторически. Про postcss сейчас думаем, возомжно позднее перейдем на него.
Зачем использовали свой css grid, а не взяли существующий?
Своего грида нет, используется flexboxgrid
Ну раз описываете продукт, могли бы уж в статью короткое описание добавить с возможностями и требованиями. А то описание звезд и прочего, а про продукт ничего нет.
А как связан данный продукт с Telegram? Вроде протокол называется MTProto V2 и при этом «MTProto V2 doesn't contain any kind of encryption and securing data is implemented by encapsulating of MTProto V2 in TLS.»
Довольно странно.
А как связан данный продукт с Telegram? Вроде протокол называется MTProto V2 и при этом «MTProto V2 doesn't contain any kind of encryption and securing data is implemented by encapsulating of MTProto V2 in TLS.»
Довольно странно.
Только историей. Я работал в Телеграме (этот акк не мой — мой забанен) и мы хотели сделать более developer-friendly телеграм что бы мы могли делать с ним какие-нибудь интересные штуки. MTProto V2 потому что это и етсь MTProto, только без шифрования. MTProto главным образом интересен своей структурой, а не шифрованием. Слой шифрования можно и заменять.
Мы доработаем доки в будущем. Хотя у нас никто кроме как в рунете не спрашивали это.
Мы доработаем доки в будущем. Хотя у нас никто кроме как в рунете не спрашивали это.
Очень бы хотелось больше технических подробностей, Ваша документация достаточно скудна, особено по серверной части.
Просто мало кто про нее спрашивал что. Мы и не писали.
Просто Ваш заголовок и статья намекают, что у Вас готовый к использованию продукт — качай (покупай), ставь и работай. А получается, что это не так, взять и развернуть просто так не получится.
Документация очень важна, хотя бы базовая, и особенно по серверной части (системные требования и требования к окружению, javadoc и пр.).
Документация очень важна, хотя бы базовая, и особенно по серверной части (системные требования и требования к окружению, javadoc и пр.).
А насколько это именно платформа? Пока я вижу скорее вполне конкретный готовый продукт, который, да, можно развернуть на своём сервере и т.д.
А насколько реально создать на этой основе свой проект БЕЗ переписывания собственно кода актора? Ну или скажем встроить в существующую ERP или что-то подобное, желательно не iframe-ом.
А насколько реально создать на этой основе свой проект БЕЗ переписывания собственно кода актора? Ну или скажем встроить в существующую ERP или что-то подобное, желательно не iframe-ом.
Вы можете взять веб-версию и адаптировать ее. Конечно нужна работа для этого (которую, кстати, можем сделать мы), кудаже без этого?
Как я уже писал ниже, имеется headless JS библиотека, реализующая апи всего месседжинга.
В процессе интеграции можно как раз получившееся выделить в апи виджетов, чтобы иметь возможность легко интегрироваться с другими продуктами, не разрабатывая UI.
В процессе интеграции можно как раз получившееся выделить в апи виджетов, чтобы иметь возможность легко интегрироваться с другими продуктами, не разрабатывая UI.
Ну headless js библиотека — это понятно, она в принципе и не так нужна если есть нормальный API.
Просто получается, что если нужна какая-то минимальная кастомная функциональность (не на уровне весь UI переписать, а буквально пару элементов добавить), есть всего два варианта:
1) переписывать существующий код и получить кучу проблем с обновлением и т.д.
2) вообще выкинуть существующий front-end код и писать его с нуля под себя
Как-то оба варианта выглядят немного странно.
Вот виджеты или компоненты или что-то такое — было бы хорошо. Или наоборот, гибкая система плагинов. То есть чтобы или 1) код актора можно было относительно безболезненно встроить в существующее окружение, или 2) наоборот, кастомную функциональность можно было дописать поверх существующего кода. Второй вариант выглядит лучше, т.к. предоставляет больше возможностей, но видимо сложнее в реализации.
Просто получается, что если нужна какая-то минимальная кастомная функциональность (не на уровне весь UI переписать, а буквально пару элементов добавить), есть всего два варианта:
1) переписывать существующий код и получить кучу проблем с обновлением и т.д.
2) вообще выкинуть существующий front-end код и писать его с нуля под себя
Как-то оба варианта выглядят немного странно.
Вот виджеты или компоненты или что-то такое — было бы хорошо. Или наоборот, гибкая система плагинов. То есть чтобы или 1) код актора можно было относительно безболезненно встроить в существующее окружение, или 2) наоборот, кастомную функциональность можно было дописать поверх существующего кода. Второй вариант выглядит лучше, т.к. предоставляет больше возможностей, но видимо сложнее в реализации.
Если вы боитесь совместимости, то вы явно не слишком увлеченный разработчик. Месседжинг — большая штука и над ней надо думать и думать много. В бесконечности может быть и появится что-то, но пока нет. Второй вариант — это и есть сделать форк и разрабатывать, а потом регулярно делать rebase.
Почему-то целому ряду проектов это оказалось полезным, а Вам кажется что нет. Сомневаюсь, что с таким подходом вы можете платить деньги.
Почему-то целому ряду проектов это оказалось полезным, а Вам кажется что нет. Сомневаюсь, что с таким подходом вы можете платить деньги.
Слушайте, ну это несерьёзный ответ. Речь вообще не о том, полезно это или нет. Речь о том, что вы себя позиционируете как ПЛАТФОРМУ.
Из ваших ответов я понимаю, что речь идёт не о платформе, а просто об опенсурсном мессенджере. Что тоже неплохо и полезно и т.д., но просто совершенно другая по сути вещь. Не было бы слова «платформа» в заголовке темы, я бы и вопросы эти задавать не стал.
Из ваших ответов я понимаю, что речь идёт не о платформе, а просто об опенсурсном мессенджере. Что тоже неплохо и полезно и т.д., но просто совершенно другая по сути вещь. Не было бы слова «платформа» в заголовке темы, я бы и вопросы эти задавать не стал.
Платформа позволяющая реализовывать новые проекты на базе наших технологий. Грубо говоря вы берете Актор и на его базе строите любую возможную коммуникационную платформу. Для начала можно на отдельных вкладках держать месседжинг и ERP. А приложения точно должны быть отдельными.
Нет, всё что я хотел выяснить я уже выяснил, в принципе можете дальше не объяснять, концепция понятна.
Можем разве что поспорить по формулировкам, хотя думаю большой пользы в этом нет. Но: если я могу создать новый продукт на базе вашего только путём форка и изменения его кода — то это не платформа, а классический опенсурсный продукт.
Можем разве что поспорить по формулировкам, хотя думаю большой пользы в этом нет. Но: если я могу создать новый продукт на базе вашего только путём форка и изменения его кода — то это не платформа, а классический опенсурсный продукт.
Ну то есть: я могу взять любой опенсурсный проект, форкнуть его и на его базе создать новый. В этом вся суть опенсурса. Но это не делает из любого опенсурсного проекта платформу для создания <нужное подставить>.
Но ещё раз, это чисто терминологическая претензия, никаких других вопросов у меня не осталось.
Но ещё раз, это чисто терминологическая претензия, никаких других вопросов у меня не осталось.
Вопрос в подготовленности системы к изменениям, Актор готов для любых доработок и в ближайшем будущем появится определенная модульность.
Ну то есть модульность планируется всё-таки? Боюсь даже спрашивать когда и в каком объёме, чтобы не перевести снова разговор на вопрос о том насколько я увлечённый разработчик и сколько могу платить.
Подозреваю, что traneblow спутал контекст с соседней дискуссией. Перейду к конструктиву.
Да, модульность планируется.
Сервер уже разбит на модули, готовится апи для удобной разработки и подключения своих модулей без вмешательства в основную кодовую базу.
С клиентами, особенно мобильными, все сложней, но, конечно, мы активно работаем и в этом направлении. Нам самим не супер удобно поддерживать разные кодовые базы под разных клиентов.
Да, модульность планируется.
Сервер уже разбит на модули, готовится апи для удобной разработки и подключения своих модулей без вмешательства в основную кодовую базу.
С клиентами, особенно мобильными, все сложней, но, конечно, мы активно работаем и в этом направлении. Нам самим не супер удобно поддерживать разные кодовые базы под разных клиентов.
И да, я не понял в какой момент и на каком основании разговор перешёл на деньги. Я что-то упустил в этом тексте?
Или я уже что-то должен вам заплатить?
В общем довольно странно вы реагируете на вопросы, которые вытекают из ваших же размытых формулировок.
Actor OpenSource edition and Cloud solutions will be always free. We believe that communications can't have any limits.
Или я уже что-то должен вам заплатить?
В общем довольно странно вы реагируете на вопросы, которые вытекают из ваших же размытых формулировок.
Кстати да, про деньги не очень уловил. На гитхабе указана лицензия распространения MIT. За что и куда еще надо платить?
Присоединяясь к вопросу про «платить деньги». Вообще, это конечно нормально и все такое, но все же лучше в таком случае озвучивать ценик и условия. А то сперва говорите, мол «пользуйтесь кто хочет, велком», а потом вместо ответов на простые вопросы начинаете сегментированием заниматься, типа «так, этот скорее всего платить не будет, можно не отвечать». Не красиво.
Актор бесплатный и всегда будет, но нам нужно дорабатывать функционал что бы всем было хорошо. Когда человек с пеной у рта с первых слов начинает обвинять проект в том что он бесполезный, то такой человек просто напросто не сможет а) доработать опенсурс проект самостоятельно б) он никогда не заплатит что бы команда спецов для него что-то сделала. В данных запросах сквозит то, что Актор ему что-то должен. Но Актор никому не должен. Тем более, мы видим большое число тех, кто реально ставит себе решение и пользуется им и доволен и дорабатывает его. В данном случае мы должны кому-то что-то сделать. В нормальном мире — no money, no honey. Это, конечно, не привычно русскому человеку осознавать. Без денег — можете проголосовать о фиче и когда-нибудь мы ее сделаем, да и если еще увидим большое число запросов. Данный человек не готов инвестировать сравнительно немного сил в то что бы встроить такой жирный и сложный функционал как мессенджер. Точнее estimate его вложений — это не больше недели чистого времени одного программиста. Это довольно типичное желание в россии — не хочу ни за что платить, не хочу ничего делать — принесите мне сразу готовое.
Интересен тот факт, что это единственое во всем интернете обсуждение правомерности называть Актор платформы, тк никто (кто действительно чего-то добился во всем мире) не считают это слово неправомерным. К слову, Телеграм — это тоже платформа, на базе которой можно много чего делать.
Интересен тот факт, что это единственое во всем интернете обсуждение правомерности называть Актор платформы, тк никто (кто действительно чего-то добился во всем мире) не считают это слово неправомерным. К слову, Телеграм — это тоже платформа, на базе которой можно много чего делать.
Один я не увидел обвинений в бесполезности?
Ребят, без обид кончено, опенсорс это очень круто и спасибо вам, но у вашей компании слегка завышено самомнение.
Ребят, без обид кончено, опенсорс это очень круто и спасибо вам, но у вашей компании слегка завышено самомнение.
Ну я примерно понимаю за что вам предыдущий аккаунт забанили.
Такой поток неадеквата (на уровне неумения читать комментарии так как они написаны, а не как они вам привиделись) в ответ на вполне нейтральные (а вообще-то даже благожелательные изначально) по тону вопросы — это показатель того, что вам явно противопоказано общаться с аудиторией.
В общем я в этом сеансе публичной психотерапевтии дальше участвовать не готов, так что adieu, далее оставляю тему в ваше полное распоряжение.
Такой поток неадеквата (на уровне неумения читать комментарии так как они написаны, а не как они вам привиделись) в ответ на вполне нейтральные (а вообще-то даже благожелательные изначально) по тону вопросы — это показатель того, что вам явно противопоказано общаться с аудиторией.
В общем я в этом сеансе публичной психотерапевтии дальше участвовать не готов, так что adieu, далее оставляю тему в ваше полное распоряжение.
На самом деле также не увидел обвинений в бесполезности. Сорри. Не уверен, что вообще есть Open-Source код, который делает что-то понятное всем, который можно было бы назвать бесполезным и к вам это точно не относиться.
Идея прекрасная, но английский текс на сайте ужасен. Нужно вычитывать и исправлять
Для чего это нужно и как это можно использовать?
Чтобы сделать, например, свой корпоративный телеграм с блекджеком и на своём сервере.
UFO just landed and posted this here
Подозреваю, что сделать сделали, а вот продать никому не смогли. Распространённая ситуация у стартапов разного рода.
Не совсем. Мы действительно не смогли продать. Точнее почти смогли, но мы просто не выглядим серьезно и нужно больше времени для компании.
Open Source оказалось лучшим решением которое мы принимали и делалось оно не как «способ выжить», а как опробация идеи. Через это любая компания проходит и должна проходить. Вынудило нас действительно то, что кончаются деньги, но скорее просто потому что мы были глупы и ничего не делали, а тут начали делать. С инвесторами мы вообще с самого начала обсуждали что будем скорее всего делать Open Source.
Open Source оказалось лучшим решением которое мы принимали и делалось оно не как «способ выжить», а как опробация идеи. Через это любая компания проходит и должна проходить. Вынудило нас действительно то, что кончаются деньги, но скорее просто потому что мы были глупы и ничего не делали, а тут начали делать. С инвесторами мы вообще с самого начала обсуждали что будем скорее всего делать Open Source.
прежде чем спрашивать «почему это стало публичным» надо сначала понять что это такое и для чего нужно.
Простите, но у вас билд фейлится
Я не очень понял сущность продукта и хотел бы запросить у автора краткое описание, что именно понимается под open-source messaging platform.
Я прочел эту статью, просмотрел промо-лэндинг, воодушевился и сразу же захотел поднять у себя эту самую открытую платформу для создания мессенджеров. Вот задача: у меня на сегодняшний день имеется некоторая сложная аппаратно-программная инфраструктура, её мониторит система мониторинга, подключенная к собственному жаббер-серверу. Если чего-то происходит, мониторинг пишет мне в жаббер, оборачивая сообщения в OTR.
Вроде бы, все работает, но мне бы хотелось вместо протокола jabber использовать более современный протокол, хотя бы тот же mproto — 2015 год на дворе. Ну и OTR для меня так уж не принципиален, ибо шифруюсь не от спецслужб, а просто от чужих любопытных глаз. Так вот, вопрос: может ли Actor Platform полноценно заменить в данной конфигурации старый добрый jabber-сервер?
Я прочел эту статью, просмотрел промо-лэндинг, воодушевился и сразу же захотел поднять у себя эту самую открытую платформу для создания мессенджеров. Вот задача: у меня на сегодняшний день имеется некоторая сложная аппаратно-программная инфраструктура, её мониторит система мониторинга, подключенная к собственному жаббер-серверу. Если чего-то происходит, мониторинг пишет мне в жаббер, оборачивая сообщения в OTR.
Вроде бы, все работает, но мне бы хотелось вместо протокола jabber использовать более современный протокол, хотя бы тот же mproto — 2015 год на дворе. Ну и OTR для меня так уж не принципиален, ибо шифруюсь не от спецслужб, а просто от чужих любопытных глаз. Так вот, вопрос: может ли Actor Platform полноценно заменить в данной конфигурации старый добрый jabber-сервер?
Я бы даже уточнил свой последний вопрос – какие примерно шаги следовало бы выполнить, чтобы Actor Platform полностью заменила в данной конфигурации старый добрый jabber-сервер?
Вы можете воспользоваться Leecero — там такой сценарий строиться за пару минут.
Более того, можно нарисовать что-то посложнее, чтобы вы спрашивали бота «что с со стойкой номер 134543» и он вам отвечал
Но он денег стоит конечно и через себя сообщения прогоняет.
Более того, можно нарисовать что-то посложнее, чтобы вы спрашивали бота «что с со стойкой номер 134543» и он вам отвечал
Но он денег стоит конечно и через себя сообщения прогоняет.
Вот да. Люди, опишите пожалуйста подробно с самого начала: что это вообще, зачем, что умеет и как с ним работать.
На всякий случай: нет, сайт и документация на эти вопросы не отвечают.
На всякий случай: нет, сайт и документация на эти вопросы не отвечают.
Лучше всего сделайте несколько готовых примеров использования.
Реквестирую вот такой: нужен мессенджер, интегрированный в некоторый абстрактный корпоративный портал.
Интегрирован — это в плане:
1. Использует уже существующие аккаунты
2. Содержит элементы UI этого портала, ну в простейшем случае — главное меню хотя бы
3. Скажем отображает какую-то кастомную информацию у контактов, вроде: должность, отдел, непосредственный руководитель
4. Ну и получает какие-то хуки, хотя вот этот пункт я в документации как раз нашёл
Если что-то из этого сейчас невозможно, планируется ли реализовывать?
Реквестирую вот такой: нужен мессенджер, интегрированный в некоторый абстрактный корпоративный портал.
Интегрирован — это в плане:
1. Использует уже существующие аккаунты
2. Содержит элементы UI этого портала, ну в простейшем случае — главное меню хотя бы
3. Скажем отображает какую-то кастомную информацию у контактов, вроде: должность, отдел, непосредственный руководитель
4. Ну и получает какие-то хуки, хотя вот этот пункт я в документации как раз нашёл
Если что-то из этого сейчас невозможно, планируется ли реализовывать?
Спасибо за конструктивный интерес к проекту!
1. Имеется поддержка oauth, на данный момент – только для gmail. Доработка поддержки других провайдеров – вопрос пары часов.
2. Имеется JS-библиотека с апи для всех функций месседжинга. Авторизация, прием-отправка сообщений, статусы сообщений, статусы пользователей, операции с группами, с контактами и т.д. Планируется создание апи виджетов.
3. Много думаем над этим, но пока не очень понятно, как это сделать универсально. Кому-то нужно общение внутри компании – там должность, отдел, непосредственный руководитель. Кому-то – b2c сервис, с информацией вроде «Клиент», «Админ», «Модератор». Очень вероятно, что скоро что-то такое будет сделано под одного из наших клиентов. Если получится сделать это универсально, смержим с открытой платформой.
4. Входящие хуки есть, да. Исходящие в планах на ближайшее будущее.
1. Имеется поддержка oauth, на данный момент – только для gmail. Доработка поддержки других провайдеров – вопрос пары часов.
2. Имеется JS-библиотека с апи для всех функций месседжинга. Авторизация, прием-отправка сообщений, статусы сообщений, статусы пользователей, операции с группами, с контактами и т.д. Планируется создание апи виджетов.
3. Много думаем над этим, но пока не очень понятно, как это сделать универсально. Кому-то нужно общение внутри компании – там должность, отдел, непосредственный руководитель. Кому-то – b2c сервис, с информацией вроде «Клиент», «Админ», «Модератор». Очень вероятно, что скоро что-то такое будет сделано под одного из наших клиентов. Если получится сделать это универсально, смержим с открытой платформой.
4. Входящие хуки есть, да. Исходящие в планах на ближайшее будущее.
3. Много думаем над этим, но пока не очень понятно, как это сделать универсально.
В теории довольно просто, не знаю насколько это так в применении к вашему конкретному случаю (могут быть какие-то ограничения со стороны реакта или вашей конкретной имплементации и т.д.): перед отрисовкой любого из основных элементов (контакт, сообщение и т.д.) кидаете эвент на который может подписаться внешний обработчик. Эвент синхронный, содержит логическое представление объекта (aka модель) и его html или dom-структуру. Во внешнем обработчике я могу отловить эвент и поменять html/dom по своему усмотрению. После этого происходит собственно отрисовка уже изменённого (ну или неизменённого если никто не менял) объекта.
Я писал проблеме универсальности не столько на уровне интерфейса, сколько на уровне API, его сущностей, методов управления ими.
Для CRM это одно, для оргструктуры организации – это другое, для массового клиентского сервиса – третье.
И управлять этим где-то нужно через интеграции, где-то явными действиями в клиентах.
В общем, пока непонятно, как это выделить в универсальную абстракцию так, чтобы ее было просто использовать и расширять.
Для CRM это одно, для оргструктуры организации – это другое, для массового клиентского сервиса – третье.
И управлять этим где-то нужно через интеграции, где-то явными действиями в клиентах.
В общем, пока непонятно, как это выделить в универсальную абстракцию так, чтобы ее было просто использовать и расширять.
сделайте мессенджер в котором будут интегрирован голос и текст распознанный по голосу (хотя бы и средствами iOS).
А сколько человек задействовано в работе над проектом, если не секрет?
Эх, как жалко, что тема сдохла.
Sign up to leave a comment.
Actor Open Messaging Platform от разработчика Telegram