Pull to refresh

Comments 13

Читаю и в очередной раз поражаюсь, насколько важны личные качества участников и их желание договариваться. В любом деле, в любом проекте.
Но вообще — вы провернули крутую штуку, молодцы.
Очень хочется верить, что всё это было проделано не зря, то есть с пользой. Для себя-то я пользу извлёк (значительно сблизившись с далёкой страной), но интересно, есть ли во всём этом какая-то польза для российского джаббера :)
Собственно, поэтому я и привёл список проектов — хотя многие из них кривы, сыры и недопилены, было бы здорово, если бы нашлись люди, которым это пригодилось бы, и было бы ещё круче, если бы кто-то смог внести свою лепту (fork, pull request, etc).
Немного отошел от Jabber-сообщества.
Подскажите, оно еще развивается или уже пошло на спад?
Т.к. на предприятиях все больше сворачивают внутренние Jabber и пользуются кто чем.
Хотя еще пару лет назад общался с партнерами через коннект серверов Jabber.
Всё зависит от того, в контексте какой страны рассматривать это самое сообщество.
У арабов, я думаю, всё ещё наблюдается развитие.
А вот в России уже достаточно давно наблюдается деградация.
Я, кстати, недавно описывал у себя в блоге вероятную причину этой деградации.
Прочитав пост в блоге: мне кажется, в вашем анализе ситуации обделены вниманием два важных момента: 1) не очень понятно, как (и почему) общая стагнация Jabber-сообщества влияет на корпоративные сервера (внутренние сервера предприятий) — про что, собственно, пишет DLag; и 2) почти все мои контакты в Jabber (как и я сам) пользуются гугловским сервисом (а не независимыми-сторонними). Который, как пишут, никто пока не собирается закрывать.

Ну то есть как: я тоже стал замечать, что Jabber все чаще стал замещаться, скажем, тем же скайпом, но обстоятельного объяснения пока не нахожу. :-(
У меня есть ещё одна гипотеза.

XMPP-протокол, считающийся очень простым, на самом деле прост лишь в теории. Он прост, когда надо просто залогиниться на сервер и отправить сообщение. Но он становится феерически сложным, когда надо делать что-то реально полезное. Большинству среднестатистических пользователей на сегодняшний день от IM-приложения нужно достаточно много: гарантированная отправка файлов, закладки на чаты, аудио и видео-вызовы. В XMPP всё это предусмотрено, но — вот беда — для любой задачи предлагается целая туча XEP-ов, то есть методов решения этой задачи. В результате разработчики клиентов (и серверов, кстати, тоже!) вынуждены метаться из стороны в сторону, не зная, что и как им реализовать. Взять те же закладки на MUC — они могут храниться как в Private XML storage, так и в pubsub. О передаче файлов я вообще молчу — там вообще туева хуча возможных способов. Идёт нарушение важного принципа, упомянутого в питоновском import this — «Должен существовать один — и, желательно, только один — очевидный способ сделать это».

Пользователи хотят от клиентов много, но им совершенно непонятны технические аспекты того, как всё это работает за кадром.
Спасибо, отличный комментарий, с тех. подробностями; то, что надо. Соглашусь насчет гарантированной доставки и передачи файлов (самое насущное): в жабере я или собеседник зачастую теряем сообщения, посланные в ε-окрестности :) времени разрыва связи; а уж настроить передачу файлов — этим, имхо, вообще почти никто не заморачивается. В том же скайпе эти фичи есть «из коробки», сразу, безо всякой настройки.
Я бы добавил, что не только сложности в реализации каких то возможностей отпугивает пользователей/программистов/администраторов, а еще и то что нет единого сервера для всех. Если рассмотреть тот же скайп, то мы ставим одно приложение которое сейчас довольно популярно и не задумываемся о том какой же сервер подключить и на коком сервере сидят его знакомые и друзья.
Это очень серьёзная проблема.

Так как если бы был один центральный сервер — всегда был бы риск разрушения сети после отключения этого сервера.
Если же серверов много, то есть если имеет место то, что мы наблюдаем сейчас, то получается как я описал у себя в блоге — тысячи бабочек-однодневок, портящих мнение технически не подкованных пользователей о всей сети. Ведь что думает простой пользователь, когда пишет другу и видит ошибку remote-server-not-found? Он не задумывается о том, что произошло, и вообще что за сервер. Он просто думает, что Psi такие вот глючные, и спокойно связывается со своим другом через Skype.

Вот если бы в сети на уровне протокола был предусмотрен автоматический, прозрачный для пользователя, выбор сервера на основании каких-то критериев (допустим, его загруженности), и прозрачную его смену в случае отказа, было бы намного лучше. Опять же, позволю себе сослаться на одну из своих предыдущих публикаций, на этот раз на jabber.ru. Сделали бы хотя бы так, то есть, не совсем прозрачно, но хотя бы какая-то балансировка загрузки, не позволяющая загнуться мелким серверам, уже была бы.
Добавлю ещё. Мне кажется, развитие Jabber и развитие XMPP надо рассматривать отдельно, а не вместе, как обычно рассматривают. Jabber это просто свободная сеть, построенная на XMPP-протоколе. Есть ли смысл делать её доступной для широких масс, идя на какие-то уступки типа скрытого от пользователя автоматического выбора сервера — это ещё большой вопрос, т/к аудитория сети уже сформировалось и, по крайней мере, в российском и индонезийском сегментах это в основном сплошные IT-шники — программисты и админы.

А под развитием XMPP надо понимать интегрирование этого протокола в существующие IM-сервисы (наподобии Skype) и разработка новых. Другими словами, для развития джаббера достаточно просто создать новый сервер или написать какой-нибудь программный проект/продукт, а вот для развития XMPP нужны уже более комплексные меры — в идеале написание нового менеджера, организация инфраструктуры, организация окупаемости всей этой штуки и т.д.
Хорошая история. Приятно осознавать, что есть люди, которые могут и делают вещи только на энтузиазме и идее, которая в них живет.
Вы молодцы! А девушка очень симпатичная. :-)
Sign up to leave a comment.

Articles