Дело не в тяжести, это так, небольшой бонус сверху. Проблема в огромном количестве софта, который это всё тянет. PHP, Ruby, Python в самом минимальном варианте, для каждого интерпретатор, сервер приложений, свой пакетный менеджер и кучу собственных пакетов. Для подобного проекта это никуда не годится — слишком много неконтролируемых точек отказа, слишком хрупкая и сложная конфигурация. Весь смысл в том, чтобы любой мало-мальски разбирающийся в компьютерах человек мог арендовать VPS, выбрать несколько пакетов по инструкции и всё, минимальный автономный узел децентрализованной сети готов. Поэтому каждый отдельный сервис должен полностью отвечать за всю функциональность, как бы это ни противоречило привычным open-source подходам.
Можно было выбрать какой-то один вариант, но это верный способ растерять кучу разработчиков, как только выйдет какой-нибудь новый модный скриптовый язык. С чистыми бинарниками всё проще в этом смысле — пишите на чём угодно — C++, Go, D, Rust, да хоть тот же Python через встроенный в бинарь интерпретатор. Лишь бы это запускалось без дополнительных зависимостей и реализовывало какой-то стандартный API / протокол.
Писать абсолютно нуля придётся в любом случае. Если предлагаемая система не будет последовательна и не будет иметь единого имиджа, то это сразу огромный удар по возможной популяризации. Только вот мне кажется, что вы переоцениваете трудоёмкость написания именно серверной части для подобного рода сервисов.
Мне просто не интересно браться за очередную игрушку для гиков. Хочу революций, на меньшее не согласен :)
Чтобы избежать зоопарка экосистем и встроить HTTP-сервер в само приложение, сохранив приемлемую производительностью для маленького слабенького VPS.
Стараниями Google & Co у меня давно зреет желание запустить такоей проект в рамках того же indiewebcamp, но я довольно далёк от веб-разработки, особенно от её клиентской части, так что пока страдаю и приглядываюсь, где можно разыскать единомышленников: )
Я так понимаю, что основной род занятий как-то связан с администрированием? :) Я пытаюсь настроить нечто подобное на cобственном VPS и мощность железа — наименьшая из проблем. Одна лишь настройка cвоего почтового сервера это боль и ужас, а потом в ход идут разные ownCloud с Diaspora и начинается полный бардак — у каждого свой язык, свой пакетный менеджер, свой HTTP сервер и т.п. Очень не хватает набора простых сервисов написанных на компилируемом языке, которые можно было бы просто поставить из репозитория, посадить за nginx и радоваться жизни.
Как сервер скажет, так и будет передаваться. Само собой тратится на пустой прогон траффика никому не нужно, но если поступит запрос от служб на прослушивание — переключат моментом.
Skype тоже уже довольно давно не p2p в том смысле. в котором о нём привыкли думать. Все супер-ноды хостятся у Microsoft.
(слова ведущего программиста отдела Voice & Video Skype)
Да какая разница. Все дело именно в federation, а то, что можно выбрать какой-то другой клиент — это настолько не важно, что мне бы и в голову не пришло рассматривать это как плюс, если бы вы не объяснили. Беда именно в том, что исчезает последний крупный мессенджер с открытой экосистемой.
Для успеха Jingle в этом ключе надо прежде всего, чтобы хоть кто-то собрал волю в кулак и написал библиотеку для voice & video под Windows. А то до сих пор ни одного нормального клиента кроме GTalk Chrome App. Но со стандартами это слабо связано.
Будут приличные клиенты под разные платформы — будет и спрос не-гиков.
Ни одна альтернатива кроме self-hosted не может гарантировать, что не упорется точно так же, как и Google. Но self-hosted альтернативы в большинстве своём довольно паршивы.
Когда в G+ у меня высветилась реклама о новых Hangout, там было написано что в GMail остаётся старый Talk в режиме совместимости и можно переключиться на новый, нажав какую-то кнопку. Я боюсь, что это сделано в виде gateway на их стороне и может быть отключено со временем.
Можно было выбрать какой-то один вариант, но это верный способ растерять кучу разработчиков, как только выйдет какой-нибудь новый модный скриптовый язык. С чистыми бинарниками всё проще в этом смысле — пишите на чём угодно — C++, Go, D, Rust, да хоть тот же Python через встроенный в бинарь интерпретатор. Лишь бы это запускалось без дополнительных зависимостей и реализовывало какой-то стандартный API / протокол.
Писать абсолютно нуля придётся в любом случае. Если предлагаемая система не будет последовательна и не будет иметь единого имиджа, то это сразу огромный удар по возможной популяризации. Только вот мне кажется, что вы переоцениваете трудоёмкость написания именно серверной части для подобного рода сервисов.
Мне просто не интересно браться за очередную игрушку для гиков. Хочу революций, на меньшее не согласен :)
Чтобы избежать зоопарка экосистем и встроить HTTP-сервер в само приложение, сохранив приемлемую производительностью для маленького слабенького VPS.
Стараниями Google & Co у меня давно зреет желание запустить такоей проект в рамках того же indiewebcamp, но я довольно далёк от веб-разработки, особенно от её клиентской части, так что пока страдаю и приглядываюсь, где можно разыскать единомышленников: )
(слова ведущего программиста отдела Voice & Video Skype)
63 в Facebook
0 в ВК
Будут приличные клиенты под разные платформы — будет и спрос не-гиков.
Так и живём.