PyGoWave Server — первый альтернативный Wave-сервер

В «очень раннем режиме», но все-таки заработал первый альтернативный Wave-сервер. Можно зарегистрироваться, создавать волны, добавлять в них других пользователей, совместно использовать гаджеты (причем можно создавать свои и делать их доступными другим). Хочется надеяться, в ближайшее время появятся и другие функции. У разработчиков есть блог. Вы также можете попробовать поставить такой сервер к себе — исходники открыты (Python, Django).

Внимание! Для использования входите через Google Chrome, через Firefox — работает не всё.

Рекомендую включить гаджет Simple Chat — это чат где сообщения появляются по мере набора.

Источник: HabraHabr

[Перевод] Google Wave: Под капотом

Усилиями группы Habratranslation переведена еще одна видеопрезентация с Google I/O
2009 - "Google Wave: Under the Hood" ("Google Wave: Под капотом").
Если вы хотели бы заняться программированием приложений для Волны, вам
важно познакомиться с принципами, на которых строится Google Wave. Эта
презентация дает некоторое представление о них.

Архитектура Объединения Google Wave

Авторы: Soren Lassen, Sam Thorogood

Перевод на русский: sim-sim, 2009, Creative Commons Attribution 3.0 License.

Оригинал: Google Wave Federation Architecture

Волны Гугл являются новой коммуникационной платформой для совместной работы, основанной на хостируемых XML документах (называемых волнами), поддерживающей параллельные модификации и обновления с коротким временем ожидания. Эта платформа позволяет людям связываться и работать вместе новым, удобным и эффективным способом. Мы собираемся предложить эти преимущества пользователям Волн Гугл и мы также хотим поделиться ими со всеми, сделав волны открытой платформой, чтобы каждый мог внести свой вклад. Мы приветствуем тех, кто запускает серверы волн и становится провайдером волн для себя или как сервис для своих пользователей, и объединяет волны в "федерацию", то есть обмеривается волнами с другими и с Волнами Гугл. Таким образом, пользователи от других провайдеров волн могут связываться и работать вместе, используя совместные волны. Мы представляем "Протокол федерации Волн Гугл" для интеграции волн между провайдерами волн в Интернете.

Этот документ дает обзор того, как различные элементы технологии Волн Гугл — модель данных, операциональные преобразования и протокол клиент-сервер — используются вместе при запуске обслуживающего сервиса волн, и как провайдеры сервисов волн связываются между собой, используя Протокол федерации Волн Гугл со своими криптографическими средствами для защиты от фальсификации. Все эти элементы описаны более подробно в сопутствующих документах на этом сайте, и читатель может обратиться к ним за деталями. Фокусом этого документа является федерация, которая включает протокол федерации волн типа "сервер-сервер", и не касается протокола типа "клиент-сервер" между клиентами и сервером волн у провайдера волн. Тем не менее, этот документ далек от исчерпывающего доклада о федерации волн. В частности, вложения (attachments) и группы — важные элементы федерации, здесь не рассматриваются. Они будут вскоре проработаны в последующих материалах на этом сайте.

Провайдеры Волн

Протокол федерации волн позволяет каждому стать провайдером волн и обмениваться волнами с остальными. Например, организация может действовать как провайдер волн для своих членов, индивид может запустить сервер волн как провайдер волн для одного потребителя или членов семьи, и провайдер услуг Интернет может запустить обслуживающий сервис волн как еще один сервис Интернет для своих потребителей, в дополнение к email, службам мгновенных сообщений, ftp и т.д. В этой модели, Волны Гугл являются одними из множества провайдеров волн.

Провайдер волн идентифицируется по своему доменному имени (именам).

Потребители волн имеют свой волновой адрес, который состоит имени потребителя и домена провайдера волн, в той же самой форме, как и email адрес, а именно @. Волновой адрес может также ссылаться на группу, роботов, хосты и другие сервисы. Групповой адрес ссылается на список волновых адресов, очень похожий на список рассылки по email. Робот является автоматизированным участником волны (см. API роботов). Примерами являются робот-переводчик и робот для игры в шахматы. Хост транслирует данные между волнами и другими коммуникациями и протоколами обмена, такими как email и мгновенных текстовых сообщений. В сухом остатке мы не придаем значения адресатам, которые являются сервисами, включая роботов и хостов — они в основном рассматриваются в качестве таких же потребителей, в том, что касается интеграции.

Потребители волн имеют доступ ко всем волнам через своего провайдера волн. Если волна имеет участника от другого провайдера волн, все их провайдеры волн поддерживают копию волны и обслуживают ее для своих потребителей волны. Провайдеры волн обмениваются обновлениями волн со всеми другими, использующими протокол федерации, который мы описываем ниже. Для любого отдельно взятого потребителя волн, ответственность по аутентификации (использование кукисов, паролей и т.д.) и локальному управлению доступа возлагается на провайдера волн в домене потребителя.

Волны, Вейвлеты и Идентификаторы

Волна состоит из набора вейвлетов (элементарных волн). Если потребитель имеет доступ к вейвлету, то он называется участником этого вейвлета. Каждый вейвлет имеет список участников и набор документов, которые верстают его содержание. Различные вейвлеты волны могут иметь разный список участников. Копии вейвлетов распространяются между всеми провайдерами волн, которые имеют хотя бы одного участника в этом вейвлете. Один особый среди таких провайдеров волн, имеет определяющую копию этого вейвлета. Мы говорим, что этот конкретный провайдер является хостером этого вейвлета.

Когда потребителю приходит волна, ему доставляется ее представление, а именно: набор вейвлетов в волне, в которой он становится участником (напрямую или косвенно, через членство в группе). В общих чертах, различные потребители имеют разные представления для одной волны. Например, конкретные данные для потребителя волны, такие как статус прочитано/непрочитано в волне, хранятся во вейвлете пользовательских данных волны только для участвующих в ней потребителей. Вейвлет пользовательских данных отображаются в представлении волны только этому участнику. Другим примером является приватные ответы внутри волны, которые отображаются как вейвлет с ограниченным списком участников. Вейвлет приватных ответов появляется в представлении волны только ограниченному списку пользователей.

Волна идентифицируется глобальным уникальным id волны, который представляет собой пару из id и доменного имени. Доменное имя указывает провайдера волны, который порождает волну.

Вейвлет имеет свой вейвлет id, который уникален внутри своей волны. Подобно id волны, вейвлет id является парой из доменного имени и строки id. Доменное имя в id вейвлета играет особую роль: оно указывает провайдера волны, который является хостером вейвлета. Вейвлет хостится у провайдера волны того участника, который создал вейвлет. Провайдер волны, который является хостером вейвлета, отвечает как за операциональные преобразования, так и за исполнение операций во вейвлете и за обмен примененных операций с провайдерами волн всех участников вейвлета.

Вейвлеты в одной и той же волне могут хостится у разных провайдеров волн. Например, вейвлет пользовательских данных всегда хостится у провайдера волн потребителя, независимо от того, где обслуживается остальная часть волны. На самом деле, пользовательские данные не являются федеральными, т.е. ими не обмениваются с другими провайдерами. Другим примером является вейвлет приватных ответов. Конкретный простой пример этого — когда все участники приватных ответов принадлежат одному и тому же провайдеру волны. В таком случае провайдер волн не обменивается вейвлетом приватных ответов с другими провайдерами волн, у которых хостятся другие ее вейвлеты.

Архитектура Обслуживающих Сервисов Волн

Провайдер волн оперирует обслуживающим сервисом волн на одном или больше серверах сети. Центральной частью сервиса волн является хранилище волн, которое хранит операции вейвлета, и сервер волн, который правит операции вейвлета с помощью операциональных преобразований, а так же записывает и читает операции вейвлета из хранилища волн. Обычно сервис волн обслуживает волны для потребителей провайдера волн, которые подключены к клиентской части сервиса волн (см. "Модель данных Гугл Волн и клиент-сервер протокол"), и мы должны иметь это ввиду в последующем описании описании архитектуры сервиса волн. Еще более важно, для целей интеграции, что сервис волн обменивается волнами с участниками от разных провайдеров, связываясь с серверами их провайдеров волн. Обслуживающий сервис волн использует два компонента для пирингового обмена с другими провайдерами волн — "хост федерации" и "удаленный узел федерации". (В ранней ревизии этой рабочей спецификации эти компоненты были названы как "шлюз федерации" и "прокси федерации", соответственно). Они описываются в следующем разделе.

Сервер волн у конкретного провайдера волн обслуживает представления волн для локальных участников, т.е. участников из своего домена. Как было описано ранее, копии вейвлетов поставляются всем провайдерам волн, которые имеют участников в этом вейвлете. Копии вейвлета у конкретного провайдера могут быть как локальными, так и удаленными. Мы используем термин "локальный вейвлет" и "удаленный вейвлет", ссылаясь на два таких типа копий вейвлета (в обоих случаях мы ссылаемся на копии вейвлета, а не на сами вейвлеты). Представление волны может содержать оба типа копий вейвлета одновременно.

У конкретного провайдера волн локальными вейвлетами являются те, что созданы у этого провайдера, а именно: теми потребителями, которые принадлежат к провайдеру вейвлета. Сервер волн является ответственным за обработку операций вейвлета, передаваемых ему локальными участниками и удаленными участниками от других провайдеров. Сервер волн управляет многопоточностью, упорядочивая передаваемые операции вейвлета относительно друг друга, используя операциональные преобразования. А так же он проверяет их корректность перед применением на локальном вейвлете.

Удаленные вейвлеты хостируют другие провайдеры волн. Сервер волн поддерживает кэшированные копии локально и обновляет их операциями вейвлета, которые получает от хостирующих провайдеров волн. Когда локальный участник отправляет вейвлетную операцию удаленному вейвлету, сервер волн пересылает операцию серверу волн хостирующего провайдера. Когда преобразованная и примененная операция возвращается обратно, она применяется на кэшированной копии. Доступ на чтение локальным участникам дается из кэшированной копии без обращения к хостирующему провайдеру волн.

Все локальные и удаленные вейвлеты хранятся в устойчивом от сбоев хранилище волн, входящему в сервер волн.

Мы говорим, что провайдер волн находится "против течения" относительно локальных вейвлетов и что он находится "по течению" по отношению к его удаленным вейвлетам.

Хост Федерации и Удаленный узел Федерации

Обслуживающий сервис волн использует два компонента для пирингового обмена с другими провайдерами волн — "хост федерации (federation host)" и "удаленный узел федерации (federation remote)".

Хост федерации обеспечивает коммуникацию локальных операций вейвлета, т.е. операций на локальном вейвлете:

• Выдает новые операции вейвлета, которые уже применены в локальном вейвлете, провайдерам волн каждого удаленного участника.
• Удовлетворяет запросы старых операций вейвлета.
• Обеспечивает согласование запросов операций вейвлета.

Удаленный узел федерации обеспечивает коммуникацию удаленных операций вейвлета и является компонентом провайдера волн, который связывается с хостом федерации вверх по течению провайдеров волн:

• Получает новые операции вейвлета, выдаваемых ему провайдерами волн, которые являются хостерами вейвлетов.
• Запрашивает старые операции вейвлета у хостирующих провайдеров волн.
• Отправляет операции вейвлета хостирующим провайдерам волн.

Хост федерации провайдера волн вверх по течению связывается с удаленным узлом федерации провайдера волн вниз по течению для передачи операций вейвлета, которые хостируются провайдером волн вверх по течению.

Для того, что бы сделать доставку операций от хоста до удаленного узла надежной, протокол федерации имеет следующие механизмы. Хост федерации поддерживает (в отказоустойчивом хранилище) очередь исходящих операций для каждого удаленного домена. Операции находятся в очереди до тех пор, пока их получение не будет подтверждено от получающего их удаленного узла федерации. Хост федерации будет постоянно пытаться установить связь и пересоединиться после любого обрыва связи (повторяя попытки с экспоненциальной задержкой). Когда связь восстанавливается, хост федерации будет передавать операции из очереди. Получающий удаленный узел возвращает подтверждения передающему хосту федерации и только тогда, когда подтверждение получено, передающая сторона удаляет из очереди подтвержденные операции.

Пример

Рассмотрим для примера вейвлет с id вейлета W (acmewave.com, conv+090528), где acmewave.com является доменом, а "conv+090528" id-строкой (структуру которой мы здесь не рассматриваем). id вейвлета предписывает, что W хостится у провайдера волн Acmewave. Предположим, что W имеет участника feddy@federati.com из другого домена federati.com.



Все операции вейвлета W, отправленные как локальными, так и удаленными участниками, преобразовываются и применяются в W, сохраняются в локальном хранилище волн провайдера Acmewave, и затем примененные операции передаются на федеральный хост, который выдает их federati.com. Хост Acmewave устанавливает связь с удаленным узлом Federati и отсылает операции через соединение.

Иногда получателю бывает нужно получить прошлые операции от отправителя. Типичным является случай, когда получены операции для вейвлета и при этом получатель не имеет всех предыдущих операций для вейвлета. (Это условие легко проверяется, потому что примененные операции содержат в себе последовательные номера версий.) В этом случае получающий удаленный узел федерации устанавливает соединение с доменом, который хостирует вейвлет и запрашивает прошлые операции, которые у него отсутствуют. (Один из случаев происходит, когда у сервера волн может создаться определенный интервал в истории операций: от момента времени t1 при удалении вейвлета, когда в его домене нет участников этого вейвлета, и до момента времени t2, когда участник из его домена присоединяется к тому же вейвлету. Хост федерации отвечает, посылая новую операцию AddParticipant, и пересылает все последующие новые операции удаленному узлу федерации, но последний должен сам откатиться и запросить предыдущие операции.)

Тем же способом потребитель может отправлять операции удаленному вейвлету, а именно позволяя хосту федерации подключаться к удаленным узлам федерации и отправляя операции на свой сервер волн.

Предположим что есть другой вейвлет, хостируемый Federati, т.е. домен id вейвлета — fedrati.com, и этот вейвлет имеет участника user@acmewave.com. Тогда хост Federati и хост Acmewave станут связываться друг с другом таким же образом.

Протокол

Сетевой протокол между хостами и удаленными узлами федерации называется "Протокол федерации Волн Гугл". Он является открытым расширением XMPP протокола обмена сообщениями через Интернет. Некоторые из ключевых полезных возможностей XMPP, которые используются в протоколе федерации волн — определение IP адресов и портов, используя SRV записи, TLS аутентификация и шифрование соединений. См. "Google Wave Federation Protocol".

Транспорт XMPP шифрует операции на транспортном уровне, таким образом, он обеспечивает криптографическую защиту только между серверами, соединенными друг с другом напрямую. Дополнительный уровень шифрования обеспечивает сквозная (end-to-end) аутентификация между провайдерами волн, использующая криптографические подписи и сертификаты, позволяя всем провайдерам вейвлета верифицировать свойства операций. В частности, провайдер волн внизу по течению может удостовериться, что провайдер волн не подделывает операции вейвлета, а именно: невозможно подделать требования (1) операций вейвлета, исходящие от потребителя другого провайдера волн или (2) того, что происходит в другом контексте. Это относится к ситуации, когда два потребителя от разных, надежных провайдеров волн, скажем love.com и peace.com, являются участниками вейвлета, который хостится у зловредного провайдера волн evil.com. Протокол требует от love.com подписывать операции своего потребителя сертификатом love.com и peace.com должен подписывать операции своего потребителя сертификатом peace.com. Эти подписи передаются вместе с операциями и evil.com должен хостировать подписи вместе с операциями. Кроме того, love.com и peace.com будут проверять подписи всех операций, которые пересылает evil.com. Это делает невозможным для evil.com изменять или подделывать содержание сообщений от потребителя love.com, которыми он делится с peace.com, и наоборот. Все подписывания и верификации осуществляются провайдерами волн, но не клиентским программным обеспечением конечных потребителей.



Спецификация протокола требует, чтобы провайдеры волн, соединяясь с использованием протокола федерации, должны обеспечивать аутентификацию используя криптографически безопасные TLS механизмы. Кроме того, рекомендуется, чтобы они использовали TLS для шифровки трафика между собой. Клиент-сервер протокол и протокол федерации не обеспечивают сквозную (end-to-end) аутентификацию или шифрование между конечными потребителями. Провайдер волн должен обеспечивать аутентификацию своих конечных потребителей, и им рекомендуется предоставлять своим конечным потребителям безопасные шифрованные соединения в своих клиентской части обслуживающего сервиса волн. Сочетание безопасных соединений между обслуживающими сервисами волн и безопасных соединений между потребителями и между самими обслуживающими сервисами волн обеспечивает достаточный уровень безопасности между конечными клиентами.


Ссылки:

Jochen Bekmann, Michael Lancaster, Soren Lassen, David Wang: "Модель данных в Волнах Гугл и Протокол клиент-сервер".
David Wang, Alex Mah: "Операциональные Преобразования в Волнах Гугл".
Danny Berlin: "Протокол федерации Волн Гугл".
Lea Kissner, Ben Laurie: "Генеральная доверенность в Федерации".

Google Wave Developer Preview at Google I/O 2009

Итак выкладываю ролик Google Wave Developer Preview at Google I/O 2009, который переведён на русский (субтитры). Многие мне пишут и спрашиваю, а в чём основные фишки Google Wave, а зачем он нужен и так далее, поэтому я решил опубликовать вам ролик, который для нас перевели участники группы переводчиков HabraTranslation.

Наконец вы узнаете то, что так давно хотели узнать, но стеснялись спросить :)

Del.icio.us : google I/O, google wave

Установка сервера Google Wave (FedOne) на локальной машине под Windows

Захотелось мне попробовать Google Wave Federation Prototype Server (FedOne) и решил я установить его на свой ноутбук под управлением Windows XP SP2.

Зачем? Ну, у меня уже был опыт комфортной разработки сайтов на своем «локальном интернете» (пакет Denwer включает Apache, PHP, MySQl и т.д.). Почему бы не поработать таким же образом с локальным волновым сервером, подумал я?
Сказано-сделано и вот, что у меня получилось. На все про все ушло часа три, причем большую часть этого времени занимала возня с установкой дополнительного программного обеспечения.

Процедура установки волнового сервера подробно и с картинками описана по-английски. Есть также русский перевод этой инструкции (сделал Иво Димитров aka Darwin).
Но установка под Windows имеет некоторые особенности, о которых я и хочу написать.

A. Необходимое программное обеспечение

Сразу скажу, что для установки волнового сервера мне понадобилось скачать:

а1. исходные тексты FedOne.

Их можно посмотреть и получить здесь.

a1.1. Mercurial

Поскольку исходники хранятся в системе управления исходными кодами Mercurial, то для их скачивания мне пришлось установить программу-клиент TortoiseHg под Windows.
В настоящее время это версия 0.8.1. — TortoiseHg-0.8.1-hg-1.3.1.exe (14.4Mb)

После установки в контекстном меню виндовского Проводника появляется субменю TortoiseHg. Создайте папку у себя на диске, установите на нее курсор, нажмите правую кнопку мыши и объявите эту папку локальным репозиторием (хранилищем) исходных кодов. Затем синхронизируйте ее с онлайновым репозиторием кодов FedOne — в Repository Settings укажите онлайновый адрес http://code.google.com/p/wave-protocol/source и закачайте файлы. И, наконец, сделайте рабочую копию этих кодов. Для этого выберите пункт Clone Repository, укажите в какую папку выложить исходники.

а2. Openfire

Это кросс-платформенный сервер взаимодействия в реальном времени, основанный на протоколе XMPP (Jabber).
Для Windows в настоящее время есть версия 3.6.4.
Предлагается для загрузки два варианта, я выбрал тот, в который включена Java RE (openfire_3_6_4.exe, 20.9Mb). Но можно, наверное, скачать и более компактный (7.49Mb) архив без JRE (а Java установить отдельно на следующем этапе).

a3. OpenSSL

Он понадобится нам для создания сертификатов нашего сервера. Я взял Windows-версию OpenSSL. А именно Light версию (весит 1Mb, есть еще 7-мегабайтная версия для разработчиков софта, но для наших целей сейчас она излишня).

a3.1.Visual C++ 2008 Redistributables

При установке оно потребовало установить Visual C++ 2008 Redistributables, пришлось скачать и установить еще и этот пакет (1.7Mb). Для этого идем на сервер Microsoft.
Замечу, что после установки VCR и перезагрузки системы инсталлятор OpenSSL все равно ругался и уверял, что VСR в системе не установлен и без него он работать не будет. Но после нажатия «OK» прекрасно все установил и заработал.

a4. Java

JavaRE6 была у меня в системе вместе с Eclipse (возможно обновилась при установке OpenFire). Но при сборке исходных кодов Ant потребовал еще файл tools.jar (около 13Mb). Он, как выяснилось, приходит вместе с пакетом для разработчиков JavaJDK. Что ж, поставим и JavaJDK.

a4.1. JavaJDK

Актуальная на данный момент версия Java6 Update14 (75Mb) доступна для закачки. (Можно взять и тут).

a5. Java-утилита Ant для сборки

Я скачивал версию 1.7.1. (10Mb).

С Ant пришлось повозиться по той причине, что ему, как я писал выше, потребовался tools.jar. Кроме того, я работаю в Windows под аккаунтом «Вадим», написанным кириллицей. Соответственно и каталоги для этой учетной записи Windows делает с кириллическими (русскими) названиями. Ant при сборке считал эти пути ошибочными и никак не хотел собирать проект.
Решил эту проблему установкой «правильных» путей (без «крокозябр») в переменных ANT_HOME, JAVA_HOME и т.п. Кстати, в доках рекомендовано установить в config.sys такую строку для работы с длинными путями: shell=c:\command.com c:\ /p /e:32768
Переменные в Windows можно установить так: правой кнопкой мыши по иконке «Мой компьютер», выбираем «Свойства». Вкладка «Дополнительно», кнопка «Переменные среды».

B. Итак, теперь собственно об установке волнового сервера.

Весь процесс разбивается на четыре этапа:
b1. настройка и запуск XMPP-сервера OpenFire
b2. генерация сертификатов OpenSSL
b3. установка волнового расширения для OpenFire, т.е. собственно настройка вашей копии сервера FedOne и его сборка
b4. запуск сервера и клиента к нему

Пройдем этот путь:

b1. Установка и настройка сервера OpenFire

Настройка OpenFire, пожалуй, самая простая часть установки сервера. Запускаете инсталлятор и следуете указаниям инструкции. По-английски или по-русски.

Поэтому повторяться не буду, но для нашего случая есть две тонкости — а) в качестве домена своего XMPP-сервера укажите "localhost", b) запомните, как назвали субдомен, используемый вашим FedOne (я назвал его "wave"), и секретное слово (shared secret) к нему (в моем примере — "foobar"). Это нам понадобится при компиляции и запуске сервера.

b2. Генерация сертификатов

По-английски описано здесь.

Все элементарно, Ватсон. Идем в C:\OpenSSL\bin\ и запускаем openssl.exe с параметрами (см. ниже). Нужно будет ответить на несколько вопросов — код страны, название города и т.п. и получить в итоге 2 файла.

Можно сделать такой genss.bat-файл:

openssl genrsa 1024 | openssl pkcs8 -topk8 -nocrypt -out %1.key
openssl req -new -x509 -nodes -sha1 -days 365 -key %1.key -out %1.cert

и запускать его так: genssl.bat wave, где wave — имя для генерируемых файлов ключей и сертификата (wave.cert и wave.key).
Кладем сгенерированные файлы в каталог с исходниками волнового сервера.

b3. Компиляция сервера и клиента

Просто перейдите в папку с исходниками сервера и скажите: «ant». (Можно предварительно прогнать тест — «ant test»).
Если у вас правильно указаны переменные и пути, то после компиляции вы получите 2 файла (fedone-0.2.jar и fedone-client-0.2.jar) в папке /dist

b4. Запуск вашего сервера и клиента к нему

Волнующий момент. :) Сделайте 2 bat-файла, для запуска сервера run-server.bat и для запуска клиента run-client.bat.

run-server.bat:

java -jar dist/fedone-0.2.jar --client_frontend_hostname=127.0.0.1 --client_frontend_port=9876 --xmpp_component_name=wave --xmpp_server_hostname=localhost --xmpp_server_ip=localhost --xmpp_server_port=5275 --xmpp_server_secret "foobar" --xmpp_server_ping="" --certificate_private_key=wave.key --certificate_files=wave.cert --certificate_domain=localhost --waveserver_disable_verification=true

p.s. Несколько пояснений: вот и пригодились нам «localhost» (наш локальный домен), «wave» (имя расширения для OpenFire) и «foobar» (секретное слово).

run-client.bat:

java -jar dist/fedone-client-0.2.jar %1@localhost 127.0.0.1 9876

Запуск клиента: run-client.bat имя_пользователя, например: run-client.bat vadbars

Итак, все готово? Он сказал, «Поехали!»

Раз. Запускаем OpenFire. В трее — желтая лампочка.
Два. Запускаем run-server. Досовское окно с протоколом запуска. Посмотрите в сообщениях, что сервер нашел OpenFire и подключился к нему. Можно посмотреть это же в админке самого OpenFire (раздел «Extentions»).
Три. Запускаем run-client. Тоже черно-белое досовское окно с какими-то малопонятными значками. А вы чего ждали? :)

Можно полюбоваться на скриншоты.

C. Работа с волнами на своем сервере и со своим клиентом

В данный момент (август 2009 года) FedOne поддерживает всего несколько команд (да-да, пока нет никакого GUI!):

/connect user@domain server port Cоединиться с server:port как участник user@domain
/open entry open Открыть волну, которая есть у вас во Входящих. Надо указать номер волны (от 0). Например: /open 1
/new Создать и открыть новую волну
/add participantId Добавить участника к волне
/remove participantId Удалить участника из волны (хе-хе, этого пока нет в клиенте Gogoole Wave Sandbox! Наш сервер круче. :)
/quit Завершить работу клиента

Автор: Вадим Барсуков

Создай свою армию роботов!

Это перевод презентации Seth Covitz "Расширение волны: создание армии роботов" ("Extending Wave: Building an Army of Robots").

После просмотра вы сможете создать своего первого робота для Google Wave!



Презентация также доступна для полноэкранного просмотра в интернете и для загрузки в виде PDF-файла.

Скажем все спасибо Вадима Герасимова!

Взято с Google Wave Russia

Установка Google Wave Server (Прототип)

Введение

Установка исходного кода Google Wave Federation Prototype Server

Исходный код Wave Federation Prototype Server поставляется в виде Java приложения, что соответствует XEP-0114, и является Jabber Component Protocol (компонентом Jabber протокола). В примере ниже мы покажем, как установить Wave Federation Prototype Server как плагин к Openfire XMPP сервер, но он должен так же работать с любым XEP-0114 совместимом сервере.

Для запуска прототипа сервера нужно сначала установить Openfire сервер. Данная инструкция Openfire сервера описывает шаги для Debian (Ubuntu) систем и если у вас возникнут проблемы или вопросы относительно установки, То обращайтесь к Openfire сообществу на их сайте.

Предварительные сведения

Openfire и Wave Federation Prototype Server разоработаны на Java поэтому вы должны убедиться, что у вас установлена Java на вашей машине. Несмотря на то, что WFPS должен работать на любой системе с Java 6 эта инструкция описывает шаги только для Debian (Ubuntu) систем.

Mac OSX

Для Mac OSX установите Java 6 с http://developer.apple.com/java/download/.

После установки Java вам надо создать переменные окружения:

$ export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
$ export PATH=$JAVA_HOME/bin:$PATH

Теперь пройдите на сайт Openfire и скачайте Mac OSX версию Openfire.

Debian/Ubuntu

Установка Java 6:

$ apt-get install sun-java6-jre sun-java6-fonts

Теперь скачайте и установите Openfire сервер:

$ wget http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire_3.6.4_all.deb
$ sudo dpkg -i openfire_3.6.4_all.deb
$ sudo /etc/init.d/openfire restart

Конфигурация Openfire (все платформы)

После установки Openfire сервера пройдите по ссылке http://localhost:9090 в вашем браузере. Замените домен на ваш, если вы устанавливаете не на локальный компьютер. Весь процесс установки будет происходить через мастер и будем ставить значения по умолчанию для простоты.

Конфигурация Openfire Wave плагина

Перезапустите сервер после окончания настройки. На Debian/Ubuntu это делается так:

$ sudo /etc/init.d/openfire/restart

После того, как перезапустите сервер войдите в Openfire как 'admin' и пароль, который вы указали.

Затем идём в Server -> Server Settings -> External Components.

Включите внешние дополнения на порту 5275 и выберите секретное слово для расшаривания этого компонента. Нажмите Сохранить. Теперь добавьте 'wave' как доверительный компонент. Для этого пишем субдомен 'wave' и напишите опять секретное слово, которое вы написали до этого. Номер порта и секретное слово служат для возможности подключения Wave дополнения.

Теперь идём в Server -> Server Settings -> Security Settings. Для "Server Connection Security" выбираем "Custom" и включаем "Server Dialback". Так же проверьте, что флажок "Accept self-signed certificates" установлен.

Защита

Следующие изменения не являются обязательными, но если вам нужна хорошая защита, то это будет хорошей практикой.

• Идём в Server -> Server Settings -> Registration and Login. Выключим "Inband Account Registration". Выключим "Change Password". Выключим "Anonymous Login"

• Включим компресию в "Compression Settings"

• Выключим прокси в "File Transfer Settings"

Установка дополнения Wave

Теперь скачиваем Federation Prototype Server и извлекаем всё содержимое. Скачать можно с SVN

Для запуска расширения вам будут нужны некоторые из параметров, который вы использовали для настройки Openfire сервера. Это номер порта, секретное слово, имя сервера и, наконец, имя компонента, которое у нас - 'wave'.

Wave сервер требует ряда сертификатов, используемых для подписания. Дополнительную информацию см. на странице Wiki.(прим. переводчика: Чуть позже сделаю перевод, как создавать сертификаты)

Отредактируйте run-server.sh скрипт с правильными настройками. Расшифровка аргументов:

Параметр	Описание
client_frontend_hostname	ip к которому будет подключаться клиент
client_frontend_port	порт к которому будет подключаться клиент
xmpp_server_hostname	XMPP сервер хост (например gogola.org)
xmpp_component_name	XMPP компонент Wave сервера. В нашем случае "wave"
xmpp_server_ip	Адрес XMPP сервера, где у нас wave компонент
xmpp_server_port	Порт XMPP сервера, где опять таки, наш компонент
xmpp_server_secret	Секретно лово компонента
xmpp_server_ping	Пинговать сервер после подключения? Если пусто, то пинговать не будет
certificate_domain	Домен сертификата который мы использовали при его создании
certificate_files	файл сертификата. (yfghbvth username.cert)
certificate_private_key	Приватный ключ сертификата (PKCS#8-PEM) (например username.key)
waveserver_disable_verification	Проверять сертификат? true - да, flase - нет

После того, как вы отредактируете скрипт сервера вам надо будет скомпилировать сервер и запустить его:

$ ant dist
$ run-server.sh

Запуск клиента

Отредактируйте run-client.sh скрипт (смотри параметры внутри скрипта), затем запустите его:

$ run-client.sh <username>