CommFort

Всем тем, кто заинтересован в разработке альтернативных клиентов (мобильные клиенты, веб клиенты и т.д.), предлагаю подключиться к разработке клиентов под наш плагин CommFort WebChat.

Все что нужно для работы с плагином:
Установка .tar.gz - вторая версия плагина. Находится в стадии альфа. Необходима разработчикам для ознакомления с API плагина.
Тестовый клиент - нужен для тестирования взаимодействия с плагином. Вы можете сразу же попробовать как работает наше API.
Обучающее видео - показывает как работать с тестовым клиентом и плагином.
Методы API - список методов, которые могут использовать альтернативные клиенты.

Сейчас плагин находится в стадии активной разработки. Список методов будет увеличиваться, будет сильно изменена логика работы плагина.
Надеюсь на активность разработчиков и буду рад помочь при возникновении проблем.

Методов API маловато, а так даже ниче

leonbratsk писал(а):Методов API маловато, а так даже ниче

Ну я же написал:

$teelR@t писал(а):Список методов будет увеличиваться

Для теста разработчикам хватит... Если не будет желающих, то хоть 200 методов будет - все равно никто не будет делать альтернативные клиенты.

$teelR@t писал(а): Для теста разработчикам хватит... Если не будет желающих, то хоть 200 методов будет - все равно никто не будет делать альтернативные клиенты.

Думаю, что будет. Самое главное это написать на java языке клиент для телефона. Если это удастся, то это будет сильный шаг в развитии коммфорта.

Самое главное это написать на java языке клиент для телефона. Если это удастся, то это будет сильный шаг в развитии коммфорта.

Ну так приступай.

~Alien~ писал(а):

Самое главное это написать на java языке клиент для телефона. Если это удастся, то это будет сильный шаг в развитии коммфорта.

Ну так приступай.

От темы не отходи.

Что-то движения никакого не замечаю.
Хотя бы выражали бы свои ЗА и ПРОТИВ разработки. А то такое впечатление, что никого из разработчиков не интересует это направление или просто никто такое не потянет (а может я прав?).

$teelR@t писал(а):Что-то движения никакого не замечаю.
Хотя бы выражали бы свои ЗА и ПРОТИВ разработки. А то такое впечатление, что никого из разработчиков не интересует это направление или просто никто такое не потянет (а может я прав?).

Я за. Вот только почти не кто не умеет писать на j2me.

_

Cilvay писал(а):возможно уйдем с голых сокетов и перейдем на ваш апи. Оставьте аську пожалуйста или какие нить другие контакты

Skype - steelteck

Оставлю и я свое слово, очень удобная, хочу отметить, система,
Например, пишем бота, он работает в отдельном процессе и следовательно не влияет на работу сервера никак, можно даже разместить на другом компьютере чтобы не тратить ресурсов.
Также можно написать программу на С++ типо оболочки, которая бы могла принимать ботов написанных для сервера и пропускать трафик через сетевой протокол, эдакий мостик для устранения всех возможных проблем с работой сервера.
Также появляется возможность писать ботов на любом языке, а как известно для обработки текстовых данных равным скриптовым языкам нету, тот же python, php ...

Сами давно таким пользуемся, года полтора наверно, мб больше (своя реализация), и боты на php, в вашей реализации самый большой минус, как по мне, так это то, что в большинстве своем сообщения небольшие в чате, в таких сообщениях 99% трафика впустую будет на оборачивание данных в протокол json. У нас протокол бинарный, минимум работы на сервере для обвертки и минимум добавочных данных в пакет для пересылки.

Cilvay писал(а):возможно уйдем с голых сокетов и перейдем на ваш апи. Оставьте аську пожалуйста или какие нить другие контакты

Для телефонов тот процент трафика который уходит на обвертку в json формат я считаю не дозволительным =)
У нас в ДВ это очень критично, к сожалению.. =(

ZigZagkms писал(а):У нас протокол бинарный, минимум работы на сервере для обвертки и минимум добавочных данных в пакет для пересылки.

Это, наверное, очень хорошо. У нас открытый протокол, с которым можно даже вручную общаться. В нем легко разобраться даже новичку. Он очень гибкий и позволяет извлекать данные в выбранном формате, чего не позволит сделать даже CommFort API. К сожалению мы не можем себе позволить делать протокол бинарным, так как подразумевается разработка под него не только нами, но и другими программистами.

ZigZagkms писал(а):

Cilvay писал(а):возможно уйдем с голых сокетов и перейдем на ваш апи. Оставьте аську пожалуйста или какие нить другие контакты

Для телефонов тот процент трафика который уходит на обвертку в json формат я считаю не дозволительным =)
У нас в ДВ это очень критично, к сожалению.. =(

Плюсов у JSON гораздо больше чем минусов. Эта обертка была выбрана как лучшая из всех рассматриваемых вариантов. Есть много готовых библиотек на всех часто употребляемых языках программирования для парсинга JSON строк. JSON формат не такой уж и громоздкий, по сравнению с xml, так что потери в производительности заметны не будут. Мы не в каменном веке, чтобы работать чисто с бинарными данными и парсить все вручную.
Потери в трафике для простых запросов минимальны, XMPP в несколько раз больше трафика потребляет и вроде никто не парится по этому поводу.

Насчет мобильной версии, трафика и каменного века. То что мобильная версия нужна для смартфонов и планшетов, а не телефонов это вроде бы понятно. В реалиях сегодняшних - большая часть наших территорий охвачена 3G-связью, но очень дорогой. Будут ли пользователи постоянно онлайн, даже если протокол будет обслуживать только список пользователей и пару каналов? Полагаю, нет. Ведь смартфон сам по себе обладает функциями связи: SMS, MMS, телефонными звонками. Так что гнаться за оперативностью получения личного сообщения в CommFort мало кто будет. А вот дома, в кафе и ресторанах, на вокзалах и в аэропортах интернет доступен по Wi-Fi, которого хватит по скоросте и цене (обычно он бесплатен) и на список пользователей, и на каналы, и на картинки. И текстовая обертка трафика не будет столь болезненна.

Я привел в пример протокол XMPP, который в качестве обертки использует XML, да еще и через HTTP может работать. Вот это где обертка - сокетам и JSON и не снилось даже... И тем не менее я не увидел никаких потерь производительности на своем медленном GPRS интернете на Андроиде.