> которые чаще всего проистекают из неверной конфигурации сервера
Не соглашусь. Уж если передавать файлы через сервер, то методом in-band работать будет всегда, гарантированно, независимо от настроек сервера, но вообще это очень плохая идея использовать сервер для передачи данных, даже если речь о прокси. Скорее, вся беда в том, что IPv6 развивается слишком медленно, иначе бы давно у всех были белые IP и необходимость в любых костылях отпала бы сама собой, а заодно сразу заработали бы нормально всяческие Jingle.
Мне вообще кажется, что вся эта шумиха вокруг якобы устаревания XMPP и деградации свободной сети Jabber связана лишь с тем, что протокол и сеть просто перешли в фазу зрелости. Критики ссылаются на то, что году в 2004-2006 писалось несоизмеримо больше ботов, транспортов, клиентов и серверов, чем сейчас, а в комнатах было больше народа. Сейчас былой активности нет, но это вполне закономерно: боты, сервера, клиенты и транспорты уже давно написаны, а сеть (Jabber) окончательно покинули те, кто просто «пробовал» её для себя.
Неудивительно — ведь узнаёт о таких сообществах обычно только сообщество IT-шников, а им такая новость вряд ли будет в радость, потому что они уже привыкли к одному, хорошо умеют с ним работать, у них есть куча готовых реализаций этого протокола. А тут им что-то новое предлагают, которое ещё и не факт, что станет стандартом RFC. В конце концов, одна из целей существования XMPP — унификация, то есть, этот протокол стремится стать единым стандартом для IM, как стал тот же HTTP для веба.
Но ведь никто, собственно, и не просит новые фичи представлять именно в виде XEP-ов. Они могли бы выпустить собственный мессенджер, в котором это было бы реализовано, а уж потом задуматься о том, чтобы предложить свои нововведения сообществу в качестве новых стандартов.
Вообще не вижу смысла гадать о причинах отказа; было бы куда интереснее, если бы свой комментарий оставил представитель вконтакта, в котором доходчиво изложил, почему XMPP объективно устарел.
Одна из серьёзных проблем XMPP — использование XML, который достаточно накладно парсить и достаточно накладно представлять в памяти. Мы с другом (по большей части он) писали свой XMPP-сервер — и я помню, как мой друг матерился на то, что XMPP использует XML. XML удобен для чтения человеком, но вовсе не «удобен» для машины. Бинарный протокол мог бы требовать на порядок меньших накладных расходов. А XMPP построен скорее теоретиками, нежели практиками.
Другая проблема XMPP, которая, правда, вряд ли могла оказать влияние на отказ вконтакта от XMPP, — это чрезмерное изобилие всяких XEP-ов, которыми стандарт основательно раздут. Для практически любой задачи существует множество решений. Закладки на MUC и сайты можно хранить как в Private Storage, так и на pubsub; для распространённой технологии vCard существует альтернатива в виде XEP-0154, которую так и приняли; способов же передачи файлов вообще уйма.
Ноги у этой проблемы растут из того факта, что XEP-ы пилятся сообществом и часто недостаточно согласованно, то есть не учитывая друг друга, а это не есть хорошо. Конечно, XMPP Council должны отвечать за такие проблемы, но, как мы можем видеть, фактически никто ни за что не отвечает.
С другой стороны, я всё-таки думаю, что считать протокол устаревшим — это как минимум странно. Об устаревании той или иной вещи говорят тогда, когда есть лучшая альтернатива. Где эта альтернатива?
Добавлю ещё. Мне кажется, развитие Jabber и развитие XMPP надо рассматривать отдельно, а не вместе, как обычно рассматривают. Jabber это просто свободная сеть, построенная на XMPP-протоколе. Есть ли смысл делать её доступной для широких масс, идя на какие-то уступки типа скрытого от пользователя автоматического выбора сервера — это ещё большой вопрос, т/к аудитория сети уже сформировалось и, по крайней мере, в российском и индонезийском сегментах это в основном сплошные IT-шники — программисты и админы.
А под развитием XMPP надо понимать интегрирование этого протокола в существующие IM-сервисы (наподобии Skype) и разработка новых. Другими словами, для развития джаббера достаточно просто создать новый сервер или написать какой-нибудь программный проект/продукт, а вот для развития XMPP нужны уже более комплексные меры — в идеале написание нового менеджера, организация инфраструктуры, организация окупаемости всей этой штуки и т.д.
Так как если бы был один центральный сервер — всегда был бы риск разрушения сети после отключения этого сервера.
Если же серверов много, то есть если имеет место то, что мы наблюдаем сейчас, то получается как я описал у себя в блоге — тысячи бабочек-однодневок, портящих мнение технически не подкованных пользователей о всей сети. Ведь что думает простой пользователь, когда пишет другу и видит ошибку remote-server-not-found? Он не задумывается о том, что произошло, и вообще что за сервер. Он просто думает, что Psi такие вот глючные, и спокойно связывается со своим другом через Skype.
Вот если бы в сети на уровне протокола был предусмотрен автоматический, прозрачный для пользователя, выбор сервера на основании каких-то критериев (допустим, его загруженности), и прозрачную его смену в случае отказа, было бы намного лучше. Опять же, позволю себе сослаться на одну из своих предыдущих публикаций, на этот раз на jabber.ru. Сделали бы хотя бы так, то есть, не совсем прозрачно, но хотя бы какая-то балансировка загрузки, не позволяющая загнуться мелким серверам, уже была бы.
XMPP-протокол, считающийся очень простым, на самом деле прост лишь в теории. Он прост, когда надо просто залогиниться на сервер и отправить сообщение. Но он становится феерически сложным, когда надо делать что-то реально полезное. Большинству среднестатистических пользователей на сегодняшний день от IM-приложения нужно достаточно много: гарантированная отправка файлов, закладки на чаты, аудио и видео-вызовы. В XMPP всё это предусмотрено, но — вот беда — для любой задачи предлагается целая туча XEP-ов, то есть методов решения этой задачи. В результате разработчики клиентов (и серверов, кстати, тоже!) вынуждены метаться из стороны в сторону, не зная, что и как им реализовать. Взять те же закладки на MUC — они могут храниться как в Private XML storage, так и в pubsub. О передаче файлов я вообще молчу — там вообще туева хуча возможных способов. Идёт нарушение важного принципа, упомянутого в питоновском import this — «Должен существовать один — и, желательно, только один — очевидный способ сделать это».
Пользователи хотят от клиентов много, но им совершенно непонятны технические аспекты того, как всё это работает за кадром.
Очень хочется верить, что всё это было проделано не зря, то есть с пользой. Для себя-то я пользу извлёк (значительно сблизившись с далёкой страной), но интересно, есть ли во всём этом какая-то польза для российского джаббера :)
Собственно, поэтому я и привёл список проектов — хотя многие из них кривы, сыры и недопилены, было бы здорово, если бы нашлись люди, которым это пригодилось бы, и было бы ещё круче, если бы кто-то смог внести свою лепту (fork, pull request, etc).
Всё зависит от того, в контексте какой страны рассматривать это самое сообщество.
У арабов, я думаю, всё ещё наблюдается развитие.
А вот в России уже достаточно давно наблюдается деградация.
Я, кстати, недавно описывал у себя в блоге вероятную причину этой деградации.
У меня есть одна песня Сергея Гринберга — «Кончается четверг, со связью плохо», когда-то данная мне им самим, но он просил её никуда не выкладывать. Так что если кто хочет, можете попробовать ему стукнуть (хотя, возможно, она и гуглится — за наличием оной найти её специально не пытался).
Не соглашусь. Уж если передавать файлы через сервер, то методом in-band работать будет всегда, гарантированно, независимо от настроек сервера, но вообще это очень плохая идея использовать сервер для передачи данных, даже если речь о прокси. Скорее, вся беда в том, что IPv6 развивается слишком медленно, иначе бы давно у всех были белые IP и необходимость в любых костылях отпала бы сама собой, а заодно сразу заработали бы нормально всяческие Jingle.
Кривая зрелости
Вообще не вижу смысла гадать о причинах отказа; было бы куда интереснее, если бы свой комментарий оставил представитель вконтакта, в котором доходчиво изложил, почему XMPP объективно устарел.
Другая проблема XMPP, которая, правда, вряд ли могла оказать влияние на отказ вконтакта от XMPP, — это чрезмерное изобилие всяких XEP-ов, которыми стандарт основательно раздут. Для практически любой задачи существует множество решений. Закладки на MUC и сайты можно хранить как в Private Storage, так и на pubsub; для распространённой технологии vCard существует альтернатива в виде XEP-0154, которую так и приняли; способов же передачи файлов вообще уйма.
Ноги у этой проблемы растут из того факта, что XEP-ы пилятся сообществом и часто недостаточно согласованно, то есть не учитывая друг друга, а это не есть хорошо. Конечно, XMPP Council должны отвечать за такие проблемы, но, как мы можем видеть, фактически никто ни за что не отвечает.
С другой стороны, я всё-таки думаю, что считать протокол устаревшим — это как минимум странно. Об устаревании той или иной вещи говорят тогда, когда есть лучшая альтернатива. Где эта альтернатива?
А под развитием XMPP надо понимать интегрирование этого протокола в существующие IM-сервисы (наподобии Skype) и разработка новых. Другими словами, для развития джаббера достаточно просто создать новый сервер или написать какой-нибудь программный проект/продукт, а вот для развития XMPP нужны уже более комплексные меры — в идеале написание нового менеджера, организация инфраструктуры, организация окупаемости всей этой штуки и т.д.
Так как если бы был один центральный сервер — всегда был бы риск разрушения сети после отключения этого сервера.
Если же серверов много, то есть если имеет место то, что мы наблюдаем сейчас, то получается как я описал у себя в блоге — тысячи бабочек-однодневок, портящих мнение технически не подкованных пользователей о всей сети. Ведь что думает простой пользователь, когда пишет другу и видит ошибку remote-server-not-found? Он не задумывается о том, что произошло, и вообще что за сервер. Он просто думает, что Psi такие вот глючные, и спокойно связывается со своим другом через Skype.
Вот если бы в сети на уровне протокола был предусмотрен автоматический, прозрачный для пользователя, выбор сервера на основании каких-то критериев (допустим, его загруженности), и прозрачную его смену в случае отказа, было бы намного лучше. Опять же, позволю себе сослаться на одну из своих предыдущих публикаций, на этот раз на jabber.ru. Сделали бы хотя бы так, то есть, не совсем прозрачно, но хотя бы какая-то балансировка загрузки, не позволяющая загнуться мелким серверам, уже была бы.
XMPP-протокол, считающийся очень простым, на самом деле прост лишь в теории. Он прост, когда надо просто залогиниться на сервер и отправить сообщение. Но он становится феерически сложным, когда надо делать что-то реально полезное. Большинству среднестатистических пользователей на сегодняшний день от IM-приложения нужно достаточно много: гарантированная отправка файлов, закладки на чаты, аудио и видео-вызовы. В XMPP всё это предусмотрено, но — вот беда — для любой задачи предлагается целая туча XEP-ов, то есть методов решения этой задачи. В результате разработчики клиентов (и серверов, кстати, тоже!) вынуждены метаться из стороны в сторону, не зная, что и как им реализовать. Взять те же закладки на MUC — они могут храниться как в Private XML storage, так и в pubsub. О передаче файлов я вообще молчу — там вообще туева хуча возможных способов. Идёт нарушение важного принципа, упомянутого в питоновском import this — «Должен существовать один — и, желательно, только один — очевидный способ сделать это».
Пользователи хотят от клиентов много, но им совершенно непонятны технические аспекты того, как всё это работает за кадром.
Собственно, поэтому я и привёл список проектов — хотя многие из них кривы, сыры и недопилены, было бы здорово, если бы нашлись люди, которым это пригодилось бы, и было бы ещё круче, если бы кто-то смог внести свою лепту (fork, pull request, etc).
У арабов, я думаю, всё ещё наблюдается развитие.
А вот в России уже достаточно давно наблюдается деградация.
Я, кстати, недавно описывал у себя в блоге вероятную причину этой деградации.
Хотя, конечно, это похоже на стрельбу из пушки по воробьям, но ведь правда же :)