>+ Когда у чата кончается память, вместо того, чтобы зависнуть, теперь чат убирает все сообщения со всех открытых каналов с экрана, в попытке освободить память.
Oobe (один из авторов чата) украл макось! Гнев Стива Джобса на него, и гнев всех лоровцев за использование проприетарщины http://i26.tinypic.com/295ahwp.jpg
>жаббер не повернуты лицом к пользователю. OSpaChat старается быть повернутым к пользователю, причем к большинству пользователей.
Вот чес слове, не понимаю людей, которые кричат подобный бред:
>жаббер не повернуты лицом к пользователю
Это как же, чтобы быть повернутым к пользователю, то надо быть отборнейшим говном и ужасным поделием или как, поясни? Или может пользователь не может понять что вместо номера надо писать nick@server.org?
Ваша аргументация о неповернутости жаббера к пользователю мягко говоря наводит на мысль о неадекватности говорящего.
>В жаббер не зайдут многие мои друзья.
У тебя друзья инвалиды с пораженным опорно двигательным аппаратом?
Может и есть какая-то аргументация этому, думаю в небольших локалках это будет востребовано. Но не надо клеймить нормальные установившиеся протоколы тем что твои имбицильные товарисчи чего то там не осиливают.
Это все такие не высшая математика и завести аккаунт на том же джаббере большого ума не требует.
Пользователи много чего не могут понять, а главное и не должны понимать, и видеть. Все должно быть просто и удобно. Вход в ирку и жаббер я не могу назвать простым, а общение в них - комфортным. Но это мое ИМХО, и с похожим мнением есть люди, для них и создан OSpaChat, чат для приятного и комфортного общения.
Маркетоидным бредом нычне никого не удивишь, а даже более - разозлишь!
>Вход в ирку и жаббер я не могу назвать простым, а общение в них - комфортным.
Как я запуская джаббер - клацаю значог, открывается окошко, выбираю статус ОНЛАЙН. Что тут сложного? Ох как сложно, да я поражен. Или может ваш чат открывается от одной только мысли? Общаться в джаббере не сложнее чем в любои быдло Квипе.
Вывод: Еще раз, не надо обсирать нормальные вещи только для того чтобы похвастаться своим поделием. В локалках такие чаты очень даже не редкость - но НЕ НАДО СРАТЬ на другие нормальные протоколы.
Такие себе протеиновые тела, сидящие где посадят и жмакающие кнопки в рандомном порядке.
>и видеть
То есть ваши пользователи даже и не видят, что жмакают - нда это уже крайний случай.
>и с похожим мнением есть люди, для них и создан OSpaChat,
Поменьше бы таких аутистов.
>чат для приятного и комфортного общения.
Эт да, но как то не укладывается в голову, что контингент на который оно расчитано вообще может общаться, а не выдавать случайные последовательности символов аля [a-A]*
Кстати, когда я вижу урл типа http://ospachat.com - то какбэ я чую скрытый намек на закрытость и проприетарность оного. Com какбэ намекает на зло, другое дело если бы там стояло org. А так очередной фейк на тему - мы вам поделку, вы кушайте нашу рекламу.
Помню как начинался jabber не было даже нормальных клиентов и сервер
глючил по черному ... много позже его произвели в статус XMPP
и положение выправилось.
Я считаю что главное в жаббере то что он распределеный !
Имеет протокол не только c2s но и s2s ! У Вас надеюсь тоже.
> ага s2s планируется и тоже будет скоро реализовано ..
Хм. Не совсем понятно ...
Тут кто то ругал за JID жаббера в формате id@server ну так это основа
использовния s2s протокола. Все ДЕЦЕНТРАЛИЗОВАНО ! Любое выпадение n
серверов из цепи не мешает работать остальным серверам в полной мере.
Поэтому несколько сложно ведение централизованого JUD но это не главное.
А как же будет у Вас выглядить ID при наличии протокола s2s ?
Спс за ссылку, growl обязательно будет.
Дизайн ИМХО позволяет общаться, но улучшать - пусть дизайнеры займуться, я не дизайнер. Основные элементы на своих местах - поле ввода, лог чата и список юзеров.
Или под "нормальным видом" имелся ввиду не дизайн? :) конкретнее.
Ну и конечно чат разрабатывается, вид будет обязательно меняться, надеюсь чтобы большинству людей он показался "нормальным" или еще лучше )
мм за JID я не ругал .. мб ообе хотя врядли конкретно за jid ..
у нас используется подобная схема .. ибо идея с жабера взята .. пока есть идея s2s , а то как конкретно реализовать и тд .. еще будем думать .. да и s2s это дополнительная фича но неявляется основой чата .. ибо позиционирование его отличается от жабера .. хотя мб и есть сходства .. тем более чат развивается и пишется примерно пол-года уже .. все может поменятся в будущих релизах
> s2s изначально планировался, поэтому аккаунты у OSpaChat
> в виде имя@сервер
Это гуд ! Но тогда не понимаю зачем нужно было огород городить.
Все можно было сделать соответствующими транспортами !
Вот я помню в свое время когда внедряли у себя на работе жаббер
( на ж.д. типа ) то не хватало нормальной реализации гейта
жаббер-мыло ... хотя может это уже сделали.
Я все-таки не понимаю, зачем было изобретать свой протокол?
Почему не написать jabber-клиент с нужными фичами и, возможно, расширениями протокола?
Да, я знаю, проще написать свой какой-нибудь протокол на коленке, чем разобраться и поддерживать XMPP, но в плюсах получаем более широкое комьюнити, лучшую совместимость и местами более продуманные решения.
А со своим протоколом получается какой-то vendor lock-in, что не очень уж в духе opensource. :)
Кстати, для вашего протокола есть клиенты для мобильных устройств (j2me версии) и web-клиенты на основе AJAX?
> 1) создание и вставка скриншотов в чат , а также картинок и в будущем передача файлов
Вставка картинок прямо в сообщение в jabber должна быть, т.к. есть поддержка html и возможность встраивать картинки в img. Возможно, это будет не очень хорошим решением из-за __РЕКОМЕНДАЦИИ__ не посылать станзы (jabber-пакеты) размером больше 64к.
> 2) куча смайлов + возможность добавления новых на сервере
Смайлики - дело клиента. Возможность обновлять набор смайлов вполне может быть реализована через механизм обновления программы.
> 3) кросплатформенность
У вас её нет.
Кроссплатформенность - это прежде всего открытый протокол, а не наличие бинарников под какую-то платформу.
> 4) сворачивание в трей
Не имеет ничего общего с протоколом. Psi вполне сворачивается в трей.
> 5) поддержка многоканальности .. с каналами в виде доски или чата
> 6) разделение доступа к личной информации .. как-то конфиг железа ип и тд
Да, сейчас vCard world-readable, но я слышал, что все-таки в этом направлении тоже что-то меняется (хотя и не могу дать ссылку на соответствующий XEP)
> 7) разделение доступа к каналам по ип или по паролю
Хех, разделение доступа по IP противоречит предыдущему пункту, кстати. ;)
А закрытые паролем комнаты и разнообразные ACL есть в Jabber MUC (multi-user chat).
> 8) аватарки :-) + выделение массаги при обращении + механизм личных сообщений ...
В vCard есть аватарки и p2p сообщения, выделение мессаги при обращении - личное дело клиента.
> 9) возможность общаться среди большой толпы народа только с интересующими тебя людьми в одном канале, иногда переключаться на разговоры с другими людьми, при этом сообщения "друзей" как бы лучше видно .. это пока реализуется
Это реализуется либо списками приватности на стороне сервера (если сообщения не хочется получать вообще), либо своеобразным игнор-листом/фильтром на стороне клиента. Поддержка списков приватности в jabber есть, но я не знаю, насколько оно хорошо работает с MUC. По идее особых проблем быть не должно, в любом случае, есть еще и второй вариант - сделать всё на стороне клиента, опять таки, в логах будет тогда полный набор мессаг :)
> 10) индикация состояния окна чата + индикация набора текста (будет)
Состояние окна чата можно вполне посылать как часть статуса, индикация набора текста стандартизирована.
> 11) индикация отсутствия активности юзверя - будет в будущем
В jabber есть возможность опроса Last activity. Но опять таки, встает вопрос приватности.
> 12) еще что-то что будет или забыл
Забыли про то, что велосипед изобретать можно... но только в двух случаях:
1) хочется разобраться в устройстве велосипеда
2) хочется сделать более совершенный велосипед :)
P.S. протокол не имеет почти ничего общего с дружественностью к пользователю, создать достаточно высокий уровень абстракции - это опять таки дело клиента. А от кнопочек/менюшек "логин", "пароль" и "войти в сеть" все равно никуда не уйти. :)
Надо знать адрес сервера? Ищите его через что-нибудь в духе zeroconf, если чат ориентирован на локалки. Это проблема клиента, а не jabber-а.
Надо знать, что такое "jabber-ресурс" и приоритеты ? Думаю, многие пользователи google talk об этом даже не догадываются. Возможно, даже не в курсе того, что можно в сеть зайти дважды.
Да, действительно, я пишу свой протокол, т.к. это проще, чем адаптироваться к имеющимся. По той же причине я пишу на Java - это проще Мне. :)
2) Про смайлики я писал выше - они должны быть одинаковыми, т.к. они выражают эмоции, а чуть-чуть разные внешне смайлики уже имеют разное значение, поэтому разные паки (наборы) смайлов не годятся.
3) Open-Source еще как есть! Во-первых это Java, которая идет почти везде, во-вторых вы не правы, это не closed-source проект. На сайте бинарники выложены для пользователей. Для всех желающих там же доступны исходники, только не с главной страницы. Исходники не пользователям нужны, поэтому не поленятся заглянуть глубже, тем более на главной странице написано и про Open-source и где взять исходники.
8) У нас не протокол, у нас в целом вся система - чат как единое целое. Это к собщению о "выделение мессаги при общении - личное дело клиента" (клиент - программа). У нас единый клиент, выглядящий и работающий одинаково на различных платформах (системах). Просто меня почему-то задело, что это дело клиента :) Да, это его дело... Но тут он един, с протоколом и вообще.
9) Речь не идет только о приватности, списках игнора и невидимости. Сейчас в чате даже нет игнора. Я его пока еще не ввел намеренно, т.к. пытаюсь реализовать (пока еще не все сделано для этого), чтобы эти старые методы борьбы с нежелательными сообщениями были не нужны. Чтобы все работало прозрачно и автоматически для пользователя. Частично сейчас это решается с помощью функции "друзей" - когда сообщения друзей выглядят ярче, с зеленой полосочкой и т.п. Но в моих планах сделать так, чтобы сообщения от нежелательных пользователю людей не мешали ему.
11) Приватность... ох. Ну если забаррикадирвоаться, что вообще не понять, человек сидит у компа или не сидит, то это будет очень неудобное общение. Я хочу сделать чат не просто приближенным к реальному общению (проще общаться в реале для этого), а сделать так, чтобы общение в нем превзошло возможности реального общения в реальной жизни. Пока что все эти функции, например состояние окна чата, позволяют лишь чуточку приблизиться к реальному общению, где видно что происходит с собеседником. Это невербальная часть и она будет наращиваться в OSpaChat.
12) Хочется более совершенный :) И хочется действительно разобраться, я начал чат писать с изучения Java и продолаю делать это - изучать. :)
Сорри, что ответил не на все вопросы, мб Магистр дополнит.
> Да, действительно, я пишу свой протокол, т.к. это проще, чем адаптироваться к имеющимся
Это, на мой взгляд, единственная причина писать свой протокол.... Так все-таки, через OSpaChat *уже* можно играть в шахматы? ;)
> Про смайлики я писал выше - они должны быть одинаковыми, т.к. они выражают эмоции, а чуть-чуть разные внешне смайлики уже имеют разное значение, поэтому разные паки (наборы) смайлов не годятся
Я и не говорил про разные наборы, я говорил про расширение наборов смайлов. В пределах одного клиента вполне возможно сохранять обратную совместимость по смайликам.
> Open-Source еще как есть! Во-первых это Java, которая идет почти везде, во-вторых вы не правы, это не closed-source проект.
Я имел ввиду полузакрытый протокол. Почему полузакрытый? Есть только одна его реализация и никто не обещает обратной совместимости.
> У нас не протокол, у нас в целом вся система - чат как единое целое. Это к собщению о "выделение мессаги при общении - личное дело клиента" (клиент - программа). У нас единый клиент, выглядящий и работающий одинаково на различных платформах (системах).
А у нас единая Россия. Интернет - это не единое целое. Интернет - это десятки тысяч автономных систем и соглашения об обмене траффиком. Да, возможно, в пределах локальной сети принимать решения "за всех" красиво и удобно, но если речь ведется о s2s и чем-то более глобальном, это не лучший подход. Я говорю лишь про то, что jabber сервер предоставляет 90% возможностей, необходимых вам. Расширять и дополнять почти всегда лушче, чем делать с нуля.
Разделять сервер и клиент - это естественно, использовать стандартные библиотеки и протоколы - это естественно. Думаю, вы же не стали переизобретать TCP, придумывать свои форматы хранения изображения и писать свои GUI-библиотеки? :)
> Речь не идет только о приватности, списках игнора и невидимости ... пытаюсь реализовать, чтобы эти старые методы борьбы с нежелательными сообщениями были не нужны
Я говорю только о технической стороне вопроса. В итоге оно все равно сведется к игнорированию сообщений на сервере через списки приватности, либо к обработке сообщений в клиенте, но это опять таки уже "дело клиента" (клиента-программы, а не клиента-человека).
Да, если игнорирование не нужно - зачем же делать разные уровни доступа к vCard?
> ... Я хочу сделать чат не просто приближенным к реальному общению (проще общаться в реале для этого), а сделать так, чтобы общение в нем превзошло возможности реального общения в реальной жизни...
"Если бы Антуан де Сент Экзюпери жил в наши дни, вероятно, его фраза «самая большая роскошь в жизни - это роскошь человеческого общения» звучала как «самая большая роскошь в жизни - это роскошь реального человеческого общения»." (С) В. Б. Николаев, открытие RuPy.Ru-2008
> Хочется более совершенный
Протокол jabber развивается с 1997го года, наверное, 10 лет потрачены не совсем впустую. Жизнь достаточно коротка, чтоб не повторять десятки раз то, что уже сделано.
>Я имел ввиду полузакрытый протокол. Почему полузакрытый? Есть только одна его реализация и никто не обещает обратной совместимости.
Обратной совместимости с чем - с другими протоколами и системаи общений... это не нужно, это "вещь в себе, самодостаточная".
Но в целом я понимаю, благодаря вашим подколкам про шахматы и другие вещи в чате, что большое сообщество уже имеющегося протокола - это интересно.
>Разделять сервер и клиент - это естественно, использовать стандартные библиотеки и протоколы - это естественно. Думаю, вы же не стали переизобретать TCP, придумывать свои форматы хранения изображения и писать свои GUI-библиотеки? :)
Да конечно, не стал. Я не стал полностью всё писать с нуля. Я остановился на некотором уровне глубины реализации. Да, я использую готовый TCP и различные библиотеки, и это здорово. Но вот "изобратаю велосипед". Да, это еще один чат. Но я такого чата не видел, поэтому и пишу. Я не видел уже собранного такого единого чата. То, что на базе irc или jabber можно сделать передачу картинок, это хорошо. То, что "где-то" есть смайлы - это ладно. Но нету собранного вместе, готового. Вы скажите - вот мне и надо было собрать... Но я решил писать с нуля чат.
>В итоге оно все равно сведется к игнорированию сообщений на сервере через списки приватности
Сведется, а мб и еще что-то будет, не важно. Главное как это со стороны пользователя - то, как это реализовано в имеющихся системах общения - меня не устраивает.
> Протокол jabber развивается с 1997го года, наверное, 10 лет потрачены не совсем впустую. Жизнь достаточно коротка, чтоб не повторять десятки раз то, что уже сделано.
Я не побоюсь, скажу, что считаю, что multy-user чат в jabber уже намного отстает от OSpaChat.
> Обратной совместимости с чем - с другими протоколами и системаи общений... это не нужно
Обратной совместимости со старыми версиями себя.
> Я не видел уже собранного такого единого чата. То, что на базе irc или jabber можно сделать передачу картинок, это хорошо. ... Но нету собранного вместе, готового. Вы скажите - вот мне и надо было собрать... Но я решил писать с нуля чат.
Собственно решение о разработке протокола с нуля мне и не нравится и я всего лишь объясняю, почему.
>>В итоге оно все равно сведется к игнорированию сообщений на сервере через списки приватности
> Сведется, а мб и еще что-то будет, не важно. Главное как это со стороны пользователя - то, как это реализовано в имеющихся системах общения - меня не устраивает.
Да, про это я и говорю, что для вас главное - клиент и его удобство. Зачем тратить время на разработку протокола, сервера и межсерверного взаимодействия, если вы хотите сосредоточиться на клиенте?
> Я не побоюсь, скажу, что считаю, что multy-user чат в jabber уже намного отстает от OSpaChat.
Вполне возможно, например, какие существенные возможности он имеет, которых нет в jabber MUC?
>> Обратной совместимости с чем - с другими протоколами и системаи общений... это не нужно
>Обратной совместимости со старыми версиями себя.
Ни в коем случае! Старые версии не поддерживаю. Я не могу представить что будет завтра с чатом - почти через день меняется чат и протокол, в итоге заложить в протокол масштабируемость не могу. Пример - седня были только сообщения, завтра уже сообщения с картинками. В случае масштарибуемого протокола, я бы заложил, что если приходит нечто, что может быть некими данными (картинкой), то игнорировать это. А в новой версии чата не игнорировал ,а показывал бы картинку на экран. Но это невомзожно, я не обладаю такой способностью все предусмотреть и предвидеть. С картинками пример простой, но заложить вообще ВСЕ, сделать очень гибким протокол - не в моих силах. Поэтому я сразу заложил в чат систему обновлений - чтобы у пользователя всегда была наиболее свежая версия чата.
Если Вы скажите, что протокол jabber как раз и есть очень гибкий, то я сомневаюсь. Я не верю :) Я не знаю правда его (протокол jabber), и впервые сегодня узнал что _рекомендуется_ ограничение на размер чего-то там на 64килобайта. Но чисто интуитивно догадываюсь, что он не такой уж и гибки. А чтобы подстроиться под него, прийдется его изучать, подстраиваться под него. Я уверен, что будет очень много граблей. К примеру в своем протоколе OSpaChat я сделал передачу картинок псевдопараллельно, что позволяет принимать, отправлять картинки и в это же время общаться в чате. Я не знаю протокола jabber, чуть представлю irc, и понимаю, что скорее всего граблями была бы именно паралелльность передачи картинок и ограничение на 64кб в частности как пример граблей в jabber. Я бы мог обойти это - например открывая прямой p2p сокет с клиентом, или как-то еще. Но это менее продуктивно по произвоительности, открытие множества сокетов хуже, чем работа по одному сокету. Это как пример, и возможно в jabber с параллельностью нет проблем. Но при входе в мультичат из клиента Psi (или Psy?) и при подгрузке сообщений из истории на своем медленном интернете я ощущал замирание всего клиента чата, до тех пор пока все сообщения не были прогружены, поэтому и подумал что этот пример может оказаться удачным.
Я уже писал, что пишу собственный протокол, т.к. мне это проще. Теперь добавлю - т.к. мне сложно изучать чужой протокол. :)
>> Я не побоюсь, скажу, что считаю, что multy-user чат в jabber уже намного отстает от OSpaChat.
>Вполне возможно, например, какие существенные возможности он имеет, которых нет в jabber MUC?
Попробую ответить, но может быть лучше посмотрите список фич чата (который кстати не полный), а главное - сами посмотрите (поживете) в OSpaChat некоторое время, чтобы оценить его возможности?. Попробую тут все-таки отетить. Я не совсем понимаю что есть jabber MUC, но если это тот текстовый чат, где только текст шарашит, от чего в глазах рябит... Как минимум OSpaChat выигрывает благодаря возможности вставки картинок (ну и на их базе - скриншотов выделенной части экрана). Опять же буду повторяться - фокусы окна - и благодаря им наличие ощущения "присутствия" - приближение к реальному общению (а в будущем благодаря другим фичам - и становление сверхреальным, лучшим чем реальное общение). А так же аватарки, которые позволяют боковым зрением вычленять нужные нам сообщения от знакомых нам пользователей (а-ля друзей). Это важные фичи, которые уже сделаны в OSpaChat, и такие фичи будут еще добавляться, не в ущерб комфорту общения, а во благо. Я ни за что не буду делать "кухонный комбайн" с кучей ненужных функций (или нужных раз в году).
В общем, так и запишем: очередной ильхамка, ляпающий из говна фигурки чтобы чсв потешить. Научись хоть свой поток сознания на абзацы разбивать, альтернативно одаренный ты наш.
>Если Вы скажите, что протокол jabber как раз и есть очень гибкий, то я сомневаюсь.
Ты просто тупой.
>Но чисто интуитивно догадываюсь, что он не такой уж и гибки
Ах интуитивно. Ну-ну. Иди и поклонись Шиве.
>А чтобы подстроиться под него, прийдется его изучать, подстраиваться под него.
Да, учиться ( и главное, думать) - это очень тяжело и больно. Растения, подобные тебе, на это просто не способны.
>Я уверен, что будет очень много граблей.
Нет, граблей в наличии только одна пара. И произрастает она прямо у тебя из плеч. Немножечко ниже того полена, на месте которого должна быть голова.
>Теперь добавлю - т.к. мне сложно изучать чужой протокол. :)
Т.к. как ты тупорылый быдлокодер. Таблицу умножения ты тоже был не в состоянии освоить ? Уйди, не позорься. Я очень надеюсь, что ты, наконец, заболеешь оспой и умрешь.
> Попробую ответить, но может быть лучше посмотрите список фич чата (который кстати не полный), а главное - сами посмотрите (поживете) в OSpaChat некоторое время, чтобы оценить его возможности?. Попробую тут все-таки отетить. Я не совсем понимаю что есть jabber MUC, но если это тот текстовый чат, где только текст шарашит, от чего в глазах рябит... Как минимум OSpaChat выигрывает благодаря возможности вставки картинок (ну и на их базе - скриншотов выделенной части экрана). Опять же буду повторяться - фокусы окна - и благодаря им наличие ощущения "присутствия" - приближение к реальному общению (а в будущем благодаря другим фичам - и становление сверхреальным, лучшим чем реальное общение). А так же аватарки, которые позволяют боковым зрением вычленять нужные нам сообщения от знакомых нам пользователей (а-ля друзей). Это важные фичи, которые уже сделаны в OSpaChat, и такие фичи будут еще добавляться, не в ущерб комфорту общения, а во благо. Я ни за что не буду делать "кухонный комбайн" с кучей ненужных функций (или нужных раз в году).
В jabber есть аватарки. В kvirc есть аватарки.
Показ аватарок рядом с сообщением дело темы клиента. Мой клиент показывает. (отключается, тема меняется).
От сплошного текста не рябит… вот от чего рябит в глазах, так это от длинных абзацев твоих.
Есть куча фич jabber'а которых не хватает в твоём больнымоспойчате, например правильная нотификация, адекватная гуя. Возможность отбирать войсы у пользователей. Игнор лист…
> Ни в коем случае! Старые версии не поддерживаю. Я не могу представить что будет завтра с чатом - почти через день меняется чат и протокол ... но может быть лучше посмотрите список фич чата
Как минимум из-за этого я воздержусь. Что-то, что _заставляет_ меня обновляться при выходне новой мажорной версии... нет, спасибо, мне не нравится «добровольно-принудительное счастье».
> Я не знаю правда протокол jabber, и впервые сегодня узнал что _рекомендуется_ ограничение на размер чего-то там на 64килобайта...
Для справки, в IRC существует ЖЕСТКОЕ ограничение на длину сообщения — 512 байт, включая необходимые CRLF в конце сообщения.
Во-первых, 64 килобайта — это достаточно много. Если сообщение не входит в 64 килобайта, стоит задуматься о том, что это не обычное небольшое сообщение, которое доставится за 0.2 секунды на другую сторону Земли, и его следует посылать каким-то другим методом.
Во-вторых, это все-таки рекомендация, а не требование, хотя я считаю, что рекомендация достаточно разумная. Кстати, в IP тоже есть жесткое ограничение на размер передаваемого пакета, и в ethernet тоже не рекомендуется пихать больше полутора килобайт.
> Но чисто интуитивно догадываюсь, что он не такой уж и гибки. ... Я уверен, что будет очень много граблей.
Да, естественно, менять все несовместимым образом каждый день - гораздо более гибкое решение, а наличие единственной верной версии избавляет от некоторых граблей. Но не слишком ли большую цену вы просите за гибкость?
Кстати, первое слово в аббревиатуре XMPP/Jabber — eXtensible :)
> К примеру в своем протоколе OSpaChat я сделал передачу картинок псевдопараллельно, что позволяет принимать, отправлять картинки и в это же время общаться в чате.
Что вы подразумеваете под псевдопараллельностью? Фрагментацию и встраивание в основной поток?
Передача файлов в jabber и IRC идет по отдельному соединению, по основному соединению идет только согласование метаинформации о передаче.
// darkk, который превысил лимит длины сообщения и разбил его на два
> Я бы мог обойти это - например открывая прямой p2p сокет с клиентом, ... Но это менее продуктивно по произвоительности, открытие множества сокетов хуже, чем работа по одному сокету.
Ложь. По крайней мере в такой формулировке. nginx может обслуживать сотни запросов в секунду на достаточно дохлом железе не создавая сумасшедшей нагрузки.
Да, для передачи смайлика оверхед установления TCP соединения заметен, 2-3 килобайта вполне можно передать и in-band, но для 100-килобайтной картинки - вполне разумен.
Да, не забудте попробовать передать образ DVD таким методом, думаю 10 человек создадут не лучшую нагрузку на сервер в таком случае.
У p2p передачи файлов я знаю ровно три минуса - проблемы при наличии NAT между пользователями (в локалке не играет роли, но стреляет в интернете), раскрытие IP адреса пользователя (тот же самый спорный вопрос о приватности) и большая сложность групповой рассылки "файлика" (из-за первых двух минусов).
> При входе в мультичат из клиента Psi и при подгрузке сообщений из истории на своем медленном интернете я ощущал замирание всего клиента чата, до тех пор пока все сообщения не были прогружены, поэтому и подумал что этот пример может оказаться удачным.
Нет, замирание всего клиента - это больше похоже на пример неудачной реализации клиента, а не пример недостатка протокола. В psi-0.12 обещают достаточно сильно переработанный код для MUC, посмотрим, что будет сделано, сейчас, согласен, в psi пользовательский интерфейс MUC реализован довольно паршиво, в tkabber получше :)
Про возможность вставки картинок я уже говорил — она формально есть и описана в документах, но фактически я не знаю клиента, который её реализует, в psi есть поддержка html, но я её всегда отключаю, т.к. цветной текст С КАртИнКАААамиИИи в моих глазах Ря-бI+ зачастую гораздо сильнее обычного текста, про фокусы окна я тоже уже говорил - проблема решается установкой статуса при потере/получении фокуса, про аватарки в vCard-ах - тоже.
>От сплошного текста не рябит… вот от чего рябит в глазах, так это от длинных абзацев твоих.
Тут - некое подобие форума, поэтому сообщения не должны быть как в чате короткими. Ведь открыв книгу, вы не скажите, что в глазах рябит, и надо, чтобы на каждой странице было по паре предложений?
>Есть куча фич jabber'а которых не хватает в твоём больнымоспойчате, например правильная нотификация
Чего именно не хватает в нотификации? Перечислите пожалуйста список того, что вам не хватает, или какие должны быть нотификации. У OSpaChat звук есть, уведомление в иконку в панели задач и в трее есть, и есть уже планы сделать, чтобы показывать больше полезной информации (т.к. уведомления разных типов, а сейчас только два типа выводятся - пришло сообщение в канал, или в приват). Будет еще всплывающий балон для виндоуз пользователей, и возможо самодельное всплывающее окошко, но это честно раздражает, я пробовал.
>Ты всё равно реализуешь игноры, рано или поздно…
Вполне возможно, что реализую. Я делаю то, что мне кажется нужным в данный момент. И то что я сейчас не сделал еще игноров, и стараюсь их избежать, вовсе не говорит о том, что они никогда не появятся в OSpaChat.
>Как минимум из-за этого я воздержусь. Что-то, что _заставляет_ меня обновляться при выходне новой мажорной версии... нет, спасибо, мне не нравится «добровольно-принудительное счастье».
Такова моя политика. Не приемлю, чтобы был зоопарк различных версий. Когда все едино и у всех одинаковый клиент, получается хорошо. Причин много... Я устал спорить с анонимусами :) Каждый все равно останется при своем мнении, и это тоже хорошо.
Большинству линуксоидов нравится свобода, и принудительные обновления на новые версии в OSpaChat им не по душе. Я понимаю это. Имеющиеся пользователи в OSpaChat напротив, радуются при появлении новой версии OSpaChat - люди ждут багфиксов и появления новых фич. Они живут в чате, как в книге или как будто смотрят фильм, живут вместе с развитием проекта OSpaChat, и участвуют в его развитии - будь то помощь кодом, дизайном, или советами и идеями.
>> К примеру в своем протоколе OSpaChat я сделал передачу картинок псевдопараллельно, что позволяет принимать, отправлять картинки и в это же время общаться в чате.
>Что вы подразумеваете под псевдопараллельностью? Фрагментацию и встраивание в основной поток?
Да, именно так. В OSpaChat картинки разбиваются на пакеты и шлются вперемешку с пакетами других картинок и текстовых сообщений, по одному потоку (сокету), что создает иллюзию параллельности. В итоге у пользователя нет тормозов и ощущения "приложение зависло, встало колом". А почему я решил использовать один сокет, а не открывать каждый раз новый я уже говорил - производительность, продуктивность. Я раньше пробовал для передачи картинки открывать новый сокет, каждый раз, т.е. на картинку по сокету - это действительно очень тяжелая операция, как для клиента, так и для сервера. Итог - тормоза и неприятные ощущения от чата у пользователя. Есть еще один способ - для данных открывать один сокет, а для текста - другой. Я так хотел сделать в этом чате, но мне не понравилась необходимость поддерживать несколько сокетов подключенными и следить за тем, что если один потеряет соединение, то надо переподключаться или что-то еще делать. Мне не понравилась эта волокита, и я решил уйти в другую волокиту - сделать свой псевдопараллельный протокол :)
>Передача файлов в jabber и IRC идет по отдельному соединению, по основному соединению идет только согласование метаинформации о передаче.
Давно давно, когда я заходил в irc, я помню такую вещь - начинаем передавать файл, возникает надпись "Ожидание установки соединения" и т.п. Это открывался новый сокет и принимался на другой стороне. И это действительно очень медленно. Накаляет. Неприятно для пользователя. В текущей ICQ это так же. В жаббере не пробовал передавать файлы.
>> Я бы мог обойти это - например открывая прямой p2p сокет с клиентом, ... Но это менее продуктивно по произвоительности, открытие множества сокетов хуже, чем работа по одному сокету.
>Ложь. По крайней мере в такой формулировке. nginx может обслуживать сотни запросов в секунду на достаточно дохлом железе не создавая сумасшедшей нагрузки.
Это не ложь, возможно это мое заблуждение. И я уже вижу в чем. Если посмотреть с одной стороны - открыть один сокет, или открывать 100 сокетов, то конечно открытие одного сокета быстрее. Но я "забываю" о том, что внутренняя реализация протокола, моя реализация, тоже создает нагрузку, которая размещает сообщения и картинки в один сокет. Но я выше уже написал, про мои наблюдения за различными программами, которые для передачи чего-либо открывают сокет - передача файла в IRC и в jabber. И как я уже выше сказал, я пробовал это сделать и в чате - для передачи каждой картинки открывать ровно 1 сокет, и это в моей реализации было очень медленно.
Кстати по поводу размера картинок, большинство картинок и скриншотов, вставляемых имеющимися в OSpaChat пользователями на сегодняшний день - небольшие картинки и скриншоты частей экрана. Часто это куски веб-страниц или отдельные фразы, в png формате.
>У p2p передачи файлов я знаю ровно три минуса - проблемы при наличии NAT между пользователями (в локалке не играет роли, но стреляет в интернете), раскрытие IP адреса пользователя (тот же самый спорный вопрос о приватности) и большая сложность групповой рассылки "файлика" (из-за первых двух минусов).
Именно так, пока что в OSpaChat еще нет p2p передачи. Но для передачи ДВД несомненно надо делать p2p :) А лучше использовать торренты или другие вещи, ведь чат - не файлообменник.
> Мне не понравилась эта волокита, и я решил уйти в другую волокиту - сделать свой псевдопараллельный протокол :)
> я пробовал это сделать и в чате - для передачи каждой картинки открывать ровно 1 сокет, и это в моей реализации было очень медленно.
Перевожу: я не сумел реализовать нормально работу с несколькими сокетами, так чтобы не тормозило, поэтому сделал так как есть.
Тебе уже привели пример: nigix создаёт сотни соединений и нормально работает. Я приведу ещё один: я был иркопом в сети, где было два сервера на UnrealIRCd и каждый держал 1500+ соединений (клиентов) одновременно на каком-то VDS с ограничением по памяти в 96Mb. Там было более 2000 каналов. И не поверишь, в UnrealIRCd это реализовано без многопоточности. Без нескольких процессов. Один процесс, один поток, 1500 соединений. А ты говоришь, что у тебя два сокета одновременно тормозят.
> Но для передачи ДВД несомненно надо делать p2p :) А лучше использовать торренты или другие вещи, ведь чат - не файлообменник.
А пользователи обязательно попробуют это сделать. И если это таки будет ложить сервер, то это DoS уязвимость.
У меня на серверной стороне тоже не используется многопоточная система, все соединения (сокеты) обрабатывает один поток, это встроено в java, а именно в java.nio.
Пример с иркой и 1500+ содеинений некорректен. Речь не идет о 1500 сокетов разных клиентов. Речь идет о том, что для загрузки сообщения с множеством картинок в оном, при плохой реализации, может использоваться много сокетов - на одного клиента. В итоге например если в сообщении 10 картинок, то при отправке 1500 клиентам данного сообщения получилось бы 15 тыс сокетов. Я выше в других сообщениях уже подробно объяснил, как я реализовал передачу сообщений, с помощью ОДНОГО сокета со стороны клиента.