Как насчет встречи?

Основанные на Internet стандарты - надежный фундамент для календарных приложений, но все же они еще очень далеки от завершения.

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

Однако в мире программ для календарного планирования намечаются перемены. Так же, как это произошло с электронной почтой, ориентированные на Internet стандарты, похоже, преобразуют и календарное ПО.

НОВЫЙ ПОДХОД

Уже сейчас многие производители предлагают системы, использующие возможности доступа World Wide Web. В числе этих производителей - Russell Information Sciences, выпустившая модуль расширения CM-Web для своих продуктов календарного планирования Calendar Manager, и Campbell Services, создатель OnTime. В конце 1996 года последняя предложила интерфейс Web для своего продукта.

В отличие от производителей календарного ПО Netscape подходит к решению задачи, так сказать, со стороны Internet. Эта компания предлагает продукт, имеющий как интерфейс Web, так и выделенного календарного клиента. Данное ПО основано на лицензионной разработке монреальской компании Corporate Software and Technologies. Netscape пытается сделать дополнительный "промоушн" своему клиенту за счет объединения его с браузером.

Преимущество доступа через Web состоит в том, что практически каждый может работать с календарем на централизованном сервере планирования и обращаться к нему с машин, не имеющих клиентского ПО. Тем не менее современное поколение программ планирования, ориентированных на Web, может послужить разве что основанием для осторожного оптимизма. С одной стороны, интерфейсы Web медленнее и загроможденнее календарных приложений с собственными клиентами. Достаточно взглянуть на приведенный на Рисунке 1 Web-интерфейс OnTime, чтобы убедиться, насколько продуманность и эффективность экранного представления выделенных календарных клиентов превосходит клиентов для браузеров. Кроме того, ни один из этих продуктов, несмотря на все те возможности, что дает им Web, не взаимодействует с другими системами планирования. Так что действительно открытые календарные системы едва вырисовываются на горизонте.

Различные проблемы взаимодействия календарных приложений призваны разрешить три предлагаемых стандарта. Это спецификация на формат данных, iCalendar, определяющая способы представления дат и времени. Есть и еще два - Calendar Interoperability Protocol (CIP) и Calendar Access Protocol (CAP), управляющие соответственно взаимодействием различных систем планирования и обработкой календарной информации на сервере. Назначение этих протоколов аналогично назначению двух основных стандартов обмена сообщениями SMTP и POP (хотя эта аналогия может оказаться не слишком удачной, поскольку POP готовится сойти со сцены, уступив место IMAP). SMTP передает электронную почту от сервера к серверу, которые взаимодействуют в реальном времени, тогда как POP и IMAP служат для получения клиентом почты с сервера.

ДАТУ ВСТРЕЧИ ИЗМЕНИТЬ НЕЛЬЗЯ

Наиболее близок к рукоположению в сан стандарта 150-страничный календарный катехизис Internet Calendaring and Scheduling Core Object Specification, а попросту - iCalendar, или COS. Этот документ стал очередной инкарнацией (версия 2.0) предыдущей спецификации, составленной Versit Consortium. Данная группа была создана компаниями Apple, AT&T, IBM и Siemens. Что касается предшественника, vCalendar, то он заложил основы обмена информацией о событиях в календаре. Эта первая работа не потеряла своего значения и теперь, во всяком случае, она помогает понять, как работают календарные стандарты. Поэтому есть прямой смысл прежде всего рассмотреть, как функционирует vCalendar.

На первый взгляд нет ничего проще, чем организовать информацию, необходимую для описания мероприятий. И в самом деле, всего-то и нужно, что знать дату, время, место и продолжительность мероприятия. В определенном смысле все именно так, и даже поверхностный взгляд на описание vCalendar обнаруживает именно эту основополагающую простоту. Так, например, назначение встречи на 30 июня 1998 года может выглядеть следующим образом:

BEGIN:VCALENDAR
VERSION:1.0
BEGIN:VEVENT
CATEGORIES:MEETING
STATUS:TENTATIVE
DTSTART:19980630T033000Z
DTEND:19980630T043000Z
SUMMARY: Встреча с Робертом 
DESCRIPTION: Встретиться с Робертом на вокзале и обсудить дела за вечерним чаем 
END:VEVENT
END:VCALENDAR

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

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

В то время как элемент BEGIN описывает различные типы календарных объектов, элемент DTSTART фактически выполняет то, ради чего и существует календарный пакет - фиксирует дату и время начала мероприятия. Формат этого компонента начинается с даты. Представление даты отличается от привычного - во-первых, дата записывается в численном виде (что не так необычно), во-вторых, в обратном порядке (6/30/98, например, выглядит как 19980630).

Время выражается подобным же образом, т. е. часы - минуты - секунды, далее следует обозначение часового пояса. К примеру, 093000Z означает 9:30 по Coordinated Universal Time (UTC) или по Гринвичу. Пояс обозначается символом Z. Если опустить Z (сокращение, обусловленное спецификацией ISO 8601), то такая запись будет означать местное время отправителя. С другой стороны, задав местное время, вы можете указать его отличие от Гринвича со знаком плюс или минус. Как правило, время и дата пишутся в одной строке с использованием Т в качестве разделителя, как это и сделано в примере с вокзалом.

В приведенном примере есть и другие строки, такие как SUMMARY и DESCRIPTION, их назначение представляется очевидным. Но другие "свойства", как называются эти куски информации, более сложны. Так, отдельное свойство позволяет определить регулярность события, т. е. насколько оно часто повторяется (например, раз в месяц, каждые 10 дней и т. д.), а также задать исключения из этого правила, например, что совещания отменяются каждую первую неделю мая.

А ВОТ И ОН - iCALENDAR

В декабре 1996 Versit Consortium передал свои полномочия по разработке vCalendar, а также электронной бизнес-карточки vCard, содержащей традиционную информацию о встречах, консорциуму Internet Mail Consortium. Консорциум финансирует рабочую группу IETF, называемую CALSCH, от английских слов calendaring и scheduling, что означает поддержку календаря и планирования. Результатом работы этой группы должна стать выработка полного набора протоколов планирования.

Идеи vCalendar были воплощены в объектной спецификации для транзакций с данными календаря, получившей название iCalendar. Хотя название последней и отличается от имени предшественницы, она, по сути, является второй версией vCalendar. Часто объекты iCalendar называются vCalendar с присовокуплением метки "версия 2.0". Когда статья готовилась к печати, спецификация iCalendar была направлена для одобрения в рабочую группу IEEE.

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

Группа CALSCH предприняла также некоторые шаги в направлении признания негрегорианских календарей. Чтобы не определять функции для обработки мероприятия из другого календаря, группа ввела атрибуты для характеристики отношений других календарей к грегорианскому.

ОБЪЕКТИВИЗАЦИЯ

Объекты iCalendar - это не более, чем куски текста, поэтому хранить и передавать их можно несколькими способами. Для начала вы можете хранить объекты в простом текстовом файле, получающем расширение .VCS (на компьютерах Macintosh это файлы типа vcal). Данный процесс практически не отличается от простого "сброса" календарной информации Personal Information Manager (PIM) в файл с разделенными запятыми значениями (Comma-Separated-Value, CSV). Однако все детали при таком подходе, скорее всего, потеряются. Так, например, пожалуй, ни одно из календарных приложений не распознает в последовательности записей о 200 совещаниях, назначенных на каждый понедельник, 10:00, повторение одного и того же события. Если понадобится перенести эти совещания на вторник - а до этого они были импортированы в формат CSV, - то придется серьезно заняться редактированием.

Кроме того, объекты можно рассматривать как MIME-компоненты типа текст/календарь. Такие объекты легко пересылать средствами электронной почты либо отдельно, либо как часть составных MIME-сообщений.

И наконец, объект можно получать по World Wide Web благодаря возможности HTTP распознавать типы MIME. Браузер, принимающий объект iCalendar, поймет, что переданную информацию типа текст/календарь ему следует обрабатывать не так, как стандартные страницы Web (тип MIME которых - текст/html).

Первое впечатление от работы iCalendar можно получить, запустив Netscape 4.0 Communicator, в который помимо разнообразных компонентов Professional Edition входит календарный клиент, поддерживающий импорт и экспорт объектов vCalendar. Если у вас есть файл с расширением .VCS событие vCalendar можно отбуксировать из Windows 95 Explorer в календарное приложение. Затем календарное приложение распознает, что имеет дело с файлом vCalendar и создает диалоговую панель (см. Рисунок 2). Так как файл .VCS может содержать несколько объектов, окно имеет стрелки для перемещения как вперед, так и назад по объектам, хранящимся в файле. Для каждого объекта пользователь может либо принять предложение (и в этом случае оно добавляется в собственный календарь пользователя), либо отказаться, т. е. не импортировать событие.

Кроме того, Netscape поставляет подключаемый компонент для браузера Navigator 4.0, который обрабатывает объекты vCalendar, полученные с узлов Web. В этом случае модуль при необходимости запускает приложение Calendar компании Netscape и переносит объекты в Calendar, где они и обрабатываются точно так же, как и при буксировке файла .VCS.

И хотя Calendar поддерживает vCalendar, само по себе приложение не использует принятого в vCalendar представления данных. Отметим, что, при взаимодействии с сервером Netscape Calendar Server, Calendar пользуется собственной схемой. В результате, если Netscape Calendar Server должен обратиться к другому календарному серверу, он этого сделать не может.

ТЫ МЕНЯ ПОНИМАЙ?

Хотя iCalendar и определяет способ представления данных, она не обеспечивает взаимодействия серверов друг с другом. Здесь-то, по выражению вице-президента по стратегии разработки продуктов компании On Technology Джея Ватсона, на сцену и выходит CIP. Находящийся в стадии предварительного проекта, этот протокол выполняет те же функции, что SMTP в мире электронной почты, обеспечивая возможность обмена информацией между различными системами планирования.

Аналогично SMTP, CIP делает возможной связь календарных серверов друг с другом через TCP/IP с использованием выделенного номера порта (назначенного IANA, Internet Assigned Numbers Authority). Во время транзакции один сервер выполняет роль сервера, в то время как другой временно исполняет обязанности клиента. Как правило, клиент обращается с запросом, а сервер пытается удовлетворить его, выполняя нужную работу или же сообщая, что по тем или иным причинам выполнить запрос невозможно. Так, например, сервер может не знать списка приглашенных на данное совещание, с другой стороны, клиент, запросивший такую информацию, может не иметь полномочий на ее получение.

На момент подготовки статьи к печати проект содержал спецификации только на четыре запроса или команды, которые клиент может направлять серверу CIP.

AUTHENTICATE обрабатывает любые необходимые процедуры регистрации и согласовывает протоколы шифрования, которые будут использоваться.

SENDEVENT - "рабочая" команда, с помощью которой клиент передает компоненты iCalendar на ожидающий их сервер.

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

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

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

ВО ЧТО ТЫ ПРЕВРАТИЛСЯ?

Если CIP - это SMTP планирования, то CAP - это POP. Иными словами, Calendar Access Protocol - это механизм, с помощью которого программное обеспечение конечного пользователя, например настольный PIM, может извлекать календарную информацию с календарного сервера. Например, если сервер А посылает сообщение о предстоящем совещании серверу В, который занимается планированием рабочего времени пользователя, сеанс CAP пошлет сообщение о совещании на его настольную систему, где работает стандартное PIM-совместимое приложение.

Но что необходимо сделать для совместимости PIM с CAP? Вряд ли сейчас кто-то может более-менее внятно ответить на этот вопрос. Питер О'Лири, вице-президент Amplitude Software и участник группы разработчиков проекта протокола CIP, пожалуй, лучше других осведомлен о деталях. Он разработал предварительную версию CAP-подобного протокола (названную iCAP, или internet Calendar Access Protocol).

"Календарные серверы и клиенты одного производителя очень тесно связаны между собой, - признает О'Лири. - Если вам симпатичен какой-либо клиент, то вы вынуждены будете использовать сервер вполне определенного производителя". Это означает, например, что, как бы вы ни любили сервер резервирования ресурсов Reserve компании Amplitude, вам не удастся просто добавить его в систему так, чтобы он работал с существующими клиентами.

Из тех трех проектов, с которыми CALSCH придется иметь дело, CAP, бесспорно, самый трудный. Каждая календарная система обрабатывает транзакции по-своему. Это касается даже таких простейших вопросов, как приглашение на совещание. Некоторые предпочитают пользоваться электронной почтой, некоторые используют подход (называемый иногда Direct Book), при котором пользователи сами пишут приглашение в календарь приглашаемого. Рабочей группе предстоит выработать стандарт, который подошел бы производителям всех систем, независимо от применяемого подхода.

Хотя CAP выполняет функцию, аналогичную POP в электронной почте, О'Лири отметил, что роль протокола ближе к более современному стандарту электронной почты - IMAP, поскольку САР позволяет работать с календарем на сервере. Это аналогично возможности IMAP обрабатывать пользовательскую почту на сервере, а не локально. Несмотря на то что календарное приложение может выполняться локально и использовать CAP только для "подгрузки" новых приглашений или ответов приглашенных, в будущем, по мнению О'Лири, большее распространение получит сценарий, в котором основным хранилищем данных из пользовательских календарей станет сервер. Клиент пользователя будет только запрашивать у сервера информацию, когда она потребуется для отображения различных видов календаря. Эта схема хранения на сервере, изображенная на Рисунке 3, особенно необходима в случае мобильных пользователей.

ВПЕРЕД К ЗОЛОТОМУ ВЕКУ

Увы, но рьяных поклонников автоматического ведения графика работ, особенно тех, кто хотел бы сделать свой календарь доступным для других, ждет разочарование. CIP и CAP еще очень далеки от реализации в коммерческих программных продуктах. Это означает, что, когда дело доходит до систем распределения ресурсов в реальном времени, каждый производитель предпочитает поддерживать собственные стандарты. И в ближайшее время, по мнению Кевина Цуротома, менеджера по продуктам, отвечающего в Netscape за Calendar, здесь изменений не предвидится.

Если что-то и может вселить надежду в этих пользователей, так это тот факт, что iCalendar (или его менее эффективный двойник - vCalendar), позволяет производителям программ работы с календарем предлагать массу нереальных прежде возможностей. Сам по себе iCalendar обеспечивает поддержку таких операций, как приглашение на совещание, прием приглашения или отказ, а также дает возможность осведомиться, свободен ли тот или иной человек либо ресурс. Без протокола, обеспечивающего передачу этих объектов iCalendar в реальном времени, обмен ими, скорее всего, будет осуществляться через электронную почту, со всеми вытекающими отсюда задержками. В напряженном ритме современной деловой жизни это не всегда позволительно, однако для рутинных дел типа еженедельных совещаний применение iCalendar-совместимых PIM, безусловно, станет огромным шагом вперед. Как только основополагающую возможность обмениваться информацией о датах и делах стандартизуют, календарное планирование получит работоспособную среду, в которой различные календарные серверы будут знать, как общаться друг с другом.

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

Вице-президент по маркетингу продуктов производителя серверов электронной почты Software.com Боб Мартин не уверен в этом. "Мне кажется, что основные производители средств электронной почты и Internet-почты - Microsoft, Lotus и Netscape - уже поняли важность средств календарного планирования и начали работать в этом направлении. Но их продукты далеко не так необходимы, как электронная почта - одно из основных средств связи вообще. Программное обеспечение для планирования работы в группах не нужно для ведения личного графика работ. Да что говорить, множество людей более чем довольны своими бумажными ежедневниками".

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

По существу, вопрос в следующем: будут ли люди пользоваться средствами календарного планирования Internet просто потому, что они есть и прилично работают? Есть все основания полагать, что так оно и будет. При работе над этой статьей автору удалось познакомиться с несколькими членами IETF, готовыми к такой форме работы.

Однако в этой связи О'Лири отметил: "Все мы в рабочей группе CALSCH применяли для планирования собственных дел различные электронные средства. И когда понадобилось организовать общее совещание, мы не смогли сделать ничего лучшего, чем договориться о нем по телефону. Это выглядело настоящей насмешкой судьбы".