Вот прямо предчувствовал, что комментирование начнётся с реквестов :)
У меня была такая мысль, так как в Comix Zone я тоже в своё время играл. Так что я думаю, что ваша просьба вполне осуществима, и если TAS-еры Comix Zone подскажут мне нужные RAM-адреса (или алгоритмы получения координат «камеры», если они в явном виде в памяти не представлены), я думаю, я смогу сделать подобное и для Comix Zone. Правда, желательно, чтобы карты уровней были без объектов на них (и, тем более, без подсказок), так как Atlas-видео с такими картами будет смотреться несколько странно. Вот, если интересно, пример не очень удачного видео. В первых трёх актах наблюдается небольшое несоответствие цветов; а в первом акте второй зоны — как раз излишняя информация на карте.
У меня такая привычка сформировалась по очень простой причине: простаивающее соединение рвёт провайдер, а запуск чего-то, что постояно гоняло трафик, решало эту проблему, теперь уже машинально запускаю, даже если исходная проблема неактуальна :)
+1, бред какой-то, я из Адыгеи, но она одинаково может считаться как входящей как в ЮФО, так и в Северный Кавказ. Проголосовал за ЮФО, потом увидел СК и поперхнулся.
Добавлю ещё. Мне кажется, развитие 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).
Всё зависит от того, в контексте какой страны рассматривать это самое сообщество.
У арабов, я думаю, всё ещё наблюдается развитие.
А вот в России уже достаточно давно наблюдается деградация.
Я, кстати, недавно описывал у себя в блоге вероятную причину этой деградации.
У меня есть одна песня Сергея Гринберга — «Кончается четверг, со связью плохо», когда-то данная мне им самим, но он просил её никуда не выкладывать. Так что если кто хочет, можете попробовать ему стукнуть (хотя, возможно, она и гуглится — за наличием оной найти её специально не пытался).
У меня была такая мысль, так как в Comix Zone я тоже в своё время играл. Так что я думаю, что ваша просьба вполне осуществима, и если TAS-еры Comix Zone подскажут мне нужные RAM-адреса (или алгоритмы получения координат «камеры», если они в явном виде в памяти не представлены), я думаю, я смогу сделать подобное и для Comix Zone. Правда, желательно, чтобы карты уровней были без объектов на них (и, тем более, без подсказок), так как Atlas-видео с такими картами будет смотреться несколько странно. Вот, если интересно, пример не очень удачного видео. В первых трёх актах наблюдается небольшое несоответствие цветов; а в первом акте второй зоны — как раз излишняя информация на карте.
А под развитием 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).
У арабов, я думаю, всё ещё наблюдается развитие.
А вот в России уже достаточно давно наблюдается деградация.
Я, кстати, недавно описывал у себя в блоге вероятную причину этой деградации.