Full-interactive web-sites

Сейчас начинает завоевывать популярность новая израильская программка Odigo. Она в принципе, умеет то же, что и ICQ, с одим важным дополнением - если ICQ предлагет общение, как таковое, то Odigo предлагает общение "по поводу" - а именно, по поводу посещаемых веб-сайтов.
В статье, рекламирующей Odigo, написано, что она реализует две простых базовых потребности людей - писать "Я был тут" и спращивать "Кто здесь"?

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

1. Общение "по поводу".

Заметим, что повод - это как правило, не сайт как таковой, а отдельный материал или реплика на сайте. И тут также имеются стандартные решения - например, наделение каждой статьи в интерактивынх издания персональными гест-буками. Но тут имеется другая проблема - в случае, когда гест-бук прикреплен к каждому материалу статье в одельности, очень трудно понять, "о чем люди пишут".

Феноменальный успех сайта forum.msk.ru в значительной степени был обеспечен моделью, при которой комментировалась каждая статья в отдельности, но имелась возможность взглянуть на
консолидированный гест-бук, понять, о чем пишут (особенно - если пишут некоторые особо уважаемые люди), и на основании этого приять решение - что, собственно, читать.

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

Таким образом, консолидация позволяла создавать из редкого потока реплик по каждой публикации в отдельности плотный общий поток реплик, являвшийся, собственно, основным контентом сайта. А деградировать эта ситуация начала, когда поток стал слишком плотным, и при этом, соответственно, некачественным.

Мораль - нужно уметь выборочно консолидировать потоки реплик к разным материаламм, и предоставлять возможность выбора уровня консолидации таким образом, чтобы поддерживать "правильную" с точки зрения участинков общения плотность потока,

Один из наиболее простых и примелимых способов - это выбирать уровни консолидации в соответсвием с некоторой иерахией комментируемых материалов. Например, для он-лайн версии офф-лапйн издания, это могут быть "Обсуждение текущего выпуска", "Обсуждение тематической рубрики".

2. Непосредственное общение.

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

Оптимальным образом эту потребность решают системы instant messaging, типа ICQ. Во первых, они обеспечивают оперативное отслеживание об участинках общения, находящихся в он-лайн, во вторых - активное уведомление о репликах в адрес участника.

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

К этому тесно примыкает потребность в "не мгновенных", но активных уведомлениях о репликах в адрес участинка, и интересующих его материалах. Таковыми являются email-рассылки.

Таким образом, можно ввести понятие Full-interactive web-site. Это сайт, обладающий следуюими характеристиками;

• любой материал, опубликованный на сайте, включая сам сайт, его тематические разделы, реплики и др., может быть откомментирован.
• существуют механизм, позволяющий управлять уровнями консолидации общения, и обеспчеивать пользователю выбор приемлимого для него уровня консолидации.
• обеспечивается регистрация участников общения и возможность информирования об участинка, находящихся в он-лайн.
• обеспечивается возможность уведомления участников об интересующих его публикациях и репликах (в том числе в его адрес), причем как через email, так и через средства Instant messaging-a.

Communiware представляет собой идеальный инструментарий для создания таких Full-interactive сатйтов.

Post-HTTP

Сегодня вся сеть построена на базе HTTP-потокола, имеющего очень простую природу: имеется масса страничек, у каждой из которых есть свой уникальный идентификатор, который впрочем может быть достаточно длинным и рабитым на несколько файлов (куки, post). Одна страничка может ссылаться на другие странички. Страничка - это стандартный HTML. И все...

Этот подход именно благодаря своей простоте позволил Сети получить тот облик, который она имеет сейчас. Мы мало это осознаем, но масса полезных сетевых сервисов (искалки, и тем более метаискалки, рейтинги, каталоги, счетчики, баннерные сети) являются МЕТАСЕРВИСАМИ, которые некоторым достаточно прозрачным образом пристраиваются к другим ресурсам ровно са счет того, что структура проста и прозрачна.

В то же время, явственнно ощущается ограниченность этой ситуации. Динамические сайты должны затрачивать массу усилий, для того, чтобы нормально подавать себя искалкам, счетчикам и рейтингам как обычные статические. Проблемы возникают даже с теми сайтами, которые формируют образы страниц с помощью JS или DHTML - их контент так просто не возмешь...

Растет популярность специализированных клиентских программ, устанавливаемых на компьютере пользователя и взаимодействующих с сервером по своим собственным протоколам. Java & ActiveX - решения, несмотря на то. что активируются из стандартного браузера, имеют ту же природу (специализирвоанного клиента). С такими системами метасервисы работать не в состоянии.
Определенные надежды в этом плане возлагаются на XML, но при том, что XML-это не более чем способ порождения языков, очевидно, что сеть начинет захлестывать вал несовместимых XML-based языков, используемых в конкретных прикладных системах. И этот процесс уже начинается. Это разнообразие и несовместимость также блокирует возможность нормальной работы метасервисов.

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

В это смысле назревает потребность в модели представления контента, которая была бы сравнима по простоте с HTML+HTTP, стандартно интерпретировалась (в отличии от XML), эффективно реализовывалась, и позволяла бы веб-ресурсам более тесно, но стандартно общаться друг с другом и с метасервисами.

Необходимо также, чтобы эта модель позволяла гибко распределять функции между сервером и клиентом обеспечивая работу как pure-браузеров, так и обеспечение данными продвинутых клиентов, реализованных на Java или на RAD-средствах.

В этом смысле контент-модель Communiware вполне удовлетворяет этим требованиям.

1. На базе этой модели легко строится практически любой веб-ресурс

2. Комунивер-сервер содержит достаточно много метаинформации, чтобы про его контент-модель можно было почти все узнать из самого сервера.

3. Разные контент - модели хорошо совместимы по крайней мере на уровне доступа к списку айтемов, типов айтемов, связей и др, и интерпретации стандартных атрибутов и стандартных типов айтемов.

4. Имеются выделенные и легко стандартизируемые протоколы для доступа к данным (базирующиеся на атрибутах и фильтрах) и для модификации данных (транзакционный интерфейс).

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

Это требует усовершенствования мехнизмов обеспечения безопасности, обеспечиваемых сейчас, но решается довольно несложно.

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

Бизнес-идеи, основанные на этих соображениях

0. (Тривиально) Платное распространение Communiware в виде продажи лицензий и хостинга как enabling technology для описанных концептов - после проведения шумной пропагандисткой компании.

1. Метасервис - дискуссионный клуб для (обычного) веб-сайта.

Предлагается услуга - создание Full-interactive Дискуссионного клуба для существующего сайта.

Рядом с сайтом создается его Communiware-слепок, повторяющий рубрикацию сайта, и рубрицированные ссылки на страницы сайта. Из этого слепка страницы исходного сайта доступны во фреймах. Этот слепок обеспечивает функции Total-interactive.

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

Сервис - бесплатен для владельцев сайта. Живет по реклмной модели, и служит проводником для продвижения как Communiware-хостинга, так и продажи лицензий.

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

2. Разработка и продвижение "слипающихся" веб-решений для отдельных предметных областей. Продвижение может базироваться на бесплатной основе. Деньги получать с интегрирующих мета-сервисов.

Например - типовое решение для агентств недвижимости. Раздается бесплатно, кастомизируется за деньги. Мы имеем мета-агентство, где мы можем предлагать весь спектр заявок, так как имеем доступ к открытой части информации тех, кто воспользовался этой системой.

Получать деньги за это можно либо по рекламной модели, либо оказывая на этом мета-сервисе платные услуги, либо получая небольшие деньги с тех, кто дает свои данные в этот мета-сервис (типа Price.ru), и/или за хостинг.

То же самое можно делать для изданий, библиотек, тур. агентств, и др.

3. Communiware search engine, Communiware portal (мета-сайт над всеми Communiware-сайтами)
Приобретает смысл при достаточной степени распостраненности Commniware-сайтов.

Технологические требованя к Communiware

1. Интеграция с ICQ
2. Разработка протоколов межсерверного взаимодействия и межсерверных ссылок.
3. Разделение CMW-сервера на брокера протокола, генератора страниц и интерпретатора интерфейсов. Протокол лучше всего оформлять в CORBA.
3. Разработка API толстого клиента, работающего с брокером протокола.