Система и способ усовершенствованного обмена сообщениями электронной почты между клиентом и сервером

Изобретение относится к средствам обмена сообщениями электронной почты. Техническим результатом является повышение производительности передачи информации с серверного компонента электронной почты. Сервер электронной почты выдает наилучший текстовый блок сообщения, доступный для сообщения электронной почты, передает объект данных полностью, если требуемое свойство или свойства не являются строго определенными внутри объекта данных, выдает данные о ходе выполнения для использования при отслеживании хода выполнения загрузки и может посылать информацию об ошибке для объекта данных, имеющего ошибку. Изменения электронной почты могут быть оптимизированы на серверном компоненте электронной почты, даже если изменения электронной почты произошли на другом серверном компоненте электронной почты. Серверный компонент электронной почты может поддерживать таблицу изменений, которые происходят в папках на ассоциированном хранилище данных, и может уведомлять подписанный клиентский компонент электронной почты об изменениях, которые происходят в таблице. 3 н. и 25 з.п. ф-лы, 31 ил., 9 табл.

 

Настоящая заявка на изобретение требует приоритет заявки США, имеющей номер 60/437 869 и номер в реестре 220635, поданной 3 января 2003 г., озаглавленной «СИСТЕМА И СПОСОБ УСОВЕРШЕНСТВОВАННОГО ОБМЕНА ИНФОРМАЦИЕЙ МЕЖДУ КЛИЕНТОМ И СЕРВЕРОМ» и включенной в данный документ путем ссылки.

Область техники, к которой относится изобретение

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

Описание предшествующего уровня техники

Электронная почта стала важным способом обмена информацией. Системы электронной почты обычно включают в себя серверный компонент (например, приложение «Microsoft Exchange Server» (Сервер обмена Microsoft)) и клиентский компонент (например, приложения «Microsoft Outlook» или «Microsoft Outlook Express» («Наблюдение» Microsoft). Такие компоненты обычно являются программными приложениями, которые настроены с возможностью исполнения на вычислительных устройствах (например, серверах, персональных компьютерах (ПК, РС), портативных компьютерах и персональных цифровых ассистентах (PDA).

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

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

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

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

Краткое описание сущности изобретения

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

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

В соответствии с другим аспектом настоящего изобретения серверный компонент электронной почты может по запросу на передачу конкретного свойства или набора свойств (например, заголовков) осуществлять передачу объекта данных полностью, если свойство или свойства не являются «хорошо» (строго) определенными внутри объекта данных. Клиентский компонент электронной почты генерирует запрос на объекты данных в папке, причем запрос включает в себя указание того, что требуемым является, по меньшей мере, одно свойство объектов данных. Серверный компонент принимает запрос и осуществляет доступ к папке и к объектам данных в папке. Для каждого объекта данных в папке, если по меньшей мере одно свойство является «хорошо» (строго) определенным в объекте данных, серверный компонент электронной почты извлекает и возвращает клиентскому компоненту электронной почты, по меньшей мере, одно свойство объекта данных. Если, по меньшей мере, одно свойство не является «хорошо» (строго) определенным для объекта данных, то серверный компонент извлекает и возвращает клиентскому компоненту электронной почты объект данных.

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

В соответствии с другим аспектом настоящего изобретения запрос, посылаемый клиентским компонентом электронной почты, может не указывать предельный размер для ответа на запрос, позволяя серверному компоненту электронной почты заполнять буфер, если необходимо. Клиентский компонент электронной почты посылает набор подзапросов внутри запроса, причем каждый из подзапросов запрашивает действие (операцию) на серверном компоненте электронной почты и включает в себя информацию о размере. В ответ на каждый подзапрос, если информация о размере включает в себя предельный размер, который находится в пределах диапазона значений, ожидаемого серверным компонентом электронной почты, то серверный компонент электронной почты ограничивает ответ до предельного размера. Если информация о размере включает в себя предельный размер, который находится вне диапазона значений, ожидаемого серверным компонентом электронной почты, тогда серверный компонент электронной почты осуществляет поиск нового значения предельного размера в информации о размере. Новый предельный размер может быть произвольным, таким чтобы «заполнить доступный буфер».

Краткое описание чертежей

Фиг.1 - схематическое представление компьютеров, соединенных сетью.

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

Фиг.3 - схематическое представление, изображающее среду с множественными версиями как клиентских компонентов электронной почты, так и серверных компонентов электронной почты.

Фиг.4 - схема протокола, показывающая пример процедуры согласования протокола между клиентским компонентом электронной почты и серверным компонентом электронной почты.

Фиг.5 - схематическое представление, показывающее примерную сеть электронной почты, в которой клиентские компоненты электронной почты и серверные компоненты электронной почты имеют буферы обмена с фиксированным размером.

Фиг.6А - схема протокола, показывающая примерный протокол, требующий два цикла «запрос-ответ» для выполнения операции быстрой передачи.

Фиг.6В - схема протокола, показывающая примерный протокол, требующий один цикл «запрос-ответ» для выполнения операции быстрой передачи.

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

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

Фиг.8А - диаграмма последовательности, иллюстрирующая режим передачи элемента данных полностью. Фиг.8В - диаграмма последовательности, иллюстрирующая режим передачи «сначала заголовки».

Фиг.8С - диаграмма последовательности, иллюстрирующая режим передачи «только заголовки».

Фиг.8D - диаграмма последовательности, иллюстрирующая переключение на режим передачи «сначала заголовки» или «только заголовки».

Фиг.9 - схема, показывающая изменяемый во времени серверный компонент электронной почты, являющийся домашним для клиентского компонента.

Фиг.10 - схема протокола, показывающая пример протокола для синхронизации папок электронной почты между клиентским компонентом электронной почты и серверным компонентом электронной почты.

Фиг.11А - блок-схема, изображающая примерную процедуру оптимизации части объекта «stateblob» (состояние большого двоичного объекта, BLOB).

Фиг.11В - блок-схема, изображающая процедуру оптимизации части объекта «stateblob» в соответствии с настоящим изобретением.

Фиг.12 - схематическое представление, иллюстрирующее иерархию папок электронной почты.

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

Фиг.14А - схема протокола, показывающая примерный протокол для обмена информацией об ошибках на уровне УОП (Удаленная операция).

Фиг.14В - схема протокола, показывающая примерный протокол для обмена информацией об ошибках на основе «по сообщению» в соответствии с аспектом настоящего изобретения.

Фиг.15А - блок-схема, иллюстрирующая процедуру генерации сообщения об ошибках на уровне УОП.

Фиг.15В - блок-схема, иллюстрирующая способ генерации сообщения об ошибках на основе «по сообщению» в соответствии с аспектом настоящего изобретения.

Фиг.16А - схема протокола, показывающая примерный протокол для выполнения операции быстрой передачи.

Фиг.16В - схема протокола, показывающая примерный протокол для обеспечения информации о ходе выполнения при выполнении операции быстрой передачи в соответствии с аспектом настоящего изобретения.

Фиг.17А - блок-схема, изображающая процедуру для потокового вывода набора сообщений.

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

Фиг.18 - принципиальная схема множественных клиентских компонентов электронной почты, уведомляемых в результате изменения в одном объекте данных на серверном компоненте электронной почты.

Фиг.19А - блок-схема, изображающая процедуру уведомления множественных абонентов.

Фиг.19В - блок-схема, изображающая процедуру уведомления множественных абонентов в соответствии с аспектом настоящего изобретения.

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

Подробное описание изобретения

Прежде чем приступить к описанию различных вариантов осуществления изобретения, приводится описание сред компьютера и передачи данных по сети, в которых могут быть реализованы различные варианты осуществления изобретения. Несмотря на то, что это не является требуемым, настоящее изобретение может быть реализовано посредством программ, которые исполняет компьютер. Обычно программы включают в себя подпрограммы, объекты, компоненты, структуры данных и подобное, что осуществляет выполнение конкретных задач или реализует конкретные абстрактные типы данных. Термин «программа», как он использован в настоящем документе, может означать одиночный программный модуль или набор программных модулей, действующих согласованно. Термин «компьютер», как он использован в настоящем документе, включает в себя любое устройство, которое электронным способом исполняет одну или несколько программ, как, например, персональные компьютеры (ПК, РС), портативные устройства, многопроцессорные системы, программируемые устройства бытовой электроники на основе микропроцессоров, сетевые ПК, миникомпьютеры, ПК графических планшетов, большие ЭВМ (или мейнфреймы), бытовые устройства, имеющие микропроцессор или микроконтроллер, маршрутизаторы, шлюзы, концентраторы и подобные. Изобретение может быть также применено в распределенной вычислительной среде, в которой задачи выполняют посредством устройств удаленной обработки, связанных через сеть передачи данных. В распределенной вычислительной среде программы могут быть расположены как на локальных, так и на удаленных устройствах хранения данных.

Пример сетевой среды, в которой может быть использовано изобретение, будет описан со ссылкой на Фиг.1. Примерная сеть включает в себя несколько компьютеров 10, осуществляющих обмен между собой по сети 11, показанной в виде облака. Сеть 11 может включать в себя известные компоненты такие, как маршрутизаторы, шлюзы, концентраторы и т.д., и позволяет компьютерам 10 осуществлять обмен информацией посредством проводного и/или беспроводного носителя. При взаимодействии между собой по сети 11 один или более компьютеров могут выступать в качестве клиентов, серверов или одноранговых узлов по отношению к остальным компьютерам. Соответственно, различные варианты осуществления могут быть применены для клиентов, серверов, одноранговых узлов или к их комбинации, несмотря на то, что конкретные примеры, содержащиеся в настоящем документе, не ссылаются на все эти типы компьютеров.Что касается Фиг.2, то на ней показан пример базовой структуры для компьютера, на котором может быть реализовано полностью или по частям изобретение, изложенное в настоящем документе. Наиболее общая структура компьютера 10 обычно включает в себя по меньшей мере один блок 14 обработки (процессор) и запоминающее устройство 16. Блок 14 обработки исполняет инструкции для выполнения задач в соответствии с различными вариантами осуществления изобретения. При выполнении таких задач блок 14 обработки может передавать электронные сигналы другим частям компьютера 10 и устройствам вне компьютера 10 для того, чтобы вызвать некоторый результат. В зависимости от конкретной структуры и типа компьютера 10 запоминающее устройство 16 может быть энергозависимым (как например, ОЗУ (RAM)), энергонезависимым (как например, ПЗУ (ROM) или флэш-память) или комбинацией перечисленных двух. Подобная наиболее общая структура проиллюстрирована на Фиг.2 с помощью пунктирной линии 18. Кроме того, компьютер также может иметь дополнительные свойства/функциональные возможности. Например, компьютер 10 может также включать в себя дополнительное внешнее хранилище данных (сменяемое 201 и/или несменяемое 202), включающее в себя магнитные или оптические диски или магнитные ленты, но не ограничиваясь перечисленными. Среда хранения, используемая компьютером, включает в себя энергозависимую и энергонезависимую, сменяемую и несменяемую среды, реализованные любым способом или технологией для хранения информации, включающими в себя исполняемые компьютером команды, структуры данных, программные модули или другие данные. Среда хранения, используемая компьютером, включает в себя, но при этом не ограничена, ОЗУ (RAM), ПЗУ (ROM), ЭСПЗУ (EPROM), флэш-память, ПЗУ на компакт-диске (CD-ROM), цифровой универсальный диск (ЦУД, DVD) или другой оптический носитель, магнитные кассеты, магнитную ленту, накопитель на магнитном диске или другие устройства с магнитным носителем, или любой другой носитель, который может быть использован для хранения требуемой информации и к которому может осуществлять доступ компьютер 10. Любая подобная используемая компьютером среда хранения может быть частью компьютера 10.

Компьютер 10 предпочтительно содержит также соединения 205 связи, которые позволяют устройству осуществлять обмен с другими устройствами. Соединение связи является примером среды передачи данных. Среда передачи данных обычно охватывает считываемые компьютером инструкции, структуры данных, программные модули или другие данные модулированного сигнала данных такого, как несущая волна или другое транспортное средство, и включает в себя любую среду доставки информации. В качестве примера, а не ограничения, термин «среда передачи данных» включает в себя проводную среду, такую как проводная сеть или соединение непосредственно проводами, и беспроводную среду такую, как акустическая, РЧ (RF), инфракрасное излучение и другие беспроводные среды. Термин «считываемый компьютером носитель» так, как он использован в настоящем документе, включает в себя как используемую компьютером среду хранения, так и среду передачи данных.

Компьютер 10 может также иметь входные устройства 204, или устройства ввода данных, такие как клавиатура, манипулятор типа «мышь», перо, устройство речевого ввода, сенсорное устройство ввода и т.д. Выходные устройства 203, или устройства вывода данных, такие как устройство 20 отображения, устройства речевого вывода, принтер и т.д., также могут быть включены в состав. Все эти устройства хорошо известны в данной области техники и не требуют дальнейшего обсуждения в настоящем документе.

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

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

При некотором событии в сетевой среде электронной почты, показанной на Фиг.3, клиентский компонент 303 электронной почты наиболее последней версии наилучшим образом осуществляет обмен информацией с серверным компонентом 306 электронной почты наиболее последней версии, используя протокол 307. Однако серверный компонент 306 электронной почты наиболее недавней (последней) версии способен также осуществлять обмен информацией с выбранными клиентскими компонентами электронной почты предыдущей версии, например с клиентским компонентом 302 электронной почты и клиентским компонентом 301 электронной почты, используя другие протоколы (например, протоколы 308 и 309 согласно Фиг.3) из набора протоколов. Клиентский компонент 303 электронной почты также способен осуществлять обмен информацией с выбранными серверными компонентами электронной почты предыдущей версии, например с серверным компонентом 305 электронной почты и с серверным компонентом 304 электронной почты, используя протоколы, такие как протоколы 310 и 311.

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

Процедуру согласования протокола часто используют для установления протокола между клиентом и сервером (например, серверным компонентом 306 электронной почты наиболее недавней версии и клиентским компонентом 303 электронной почты наиболее недавней версии). Несмотря на то, что такие согласования протоколов известны, для облегчения восприятия (читателем) приведено краткое описание процедуры согласования протокола между клиентским компонентом 401 (Фиг.4) электронной почты и серверным компонентом 402 (также Фиг.4). Ранее в сеансе связи электронной почты между клиентским компонентом 401 электронной почты и серверным компонентом 402 электронной почты клиентский компонент 401 посылает серверному компоненту 402 электронной почты сообщение 403, которое включает в себя информацию о версии клиента, например, в виде отметки (или штампа) версии клиентского компонента. Серверный компонент 402 электронной почты отвечает на сообщение 403 посредством сообщения 404, которое включает в себя информацию о версии сервера, например, в виде отметки (или штампа) версии серверного компонента.

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

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

Сеть электронной почты настоящего изобретения использует обмены запросами и ответами для передачи запросов и данных между клиентскими и серверными компонентами в сети. На практике на производительность протокола может влиять лежащий в основе (базовый) транспортный механизм сети связи, используемый для реализации обмена информацией между клиентами и серверами в сети электронной почты. Например, в сети электронной почты, которая использует удаленные вызовы процедур (УВП, RPC) в качестве базового транспортного механизма обмена информацией, может быть более эффективным выполнение одиночного удаленного вызова процедуры с более значительным объемом (например, 32 кБ), чем выполнение нескольких удаленных вызовов процедур с меньшим объемом (например, 2 кБ). Одним известным способом для повышения производительности в таких сетях электронной почты является буферизация множественных запросов и/или ответов для передачи в одиночном удаленном вызове процедуры.

В качестве примера на Фиг.5 показан обмен запросом и ответом между клиентским компонентом 501 электронной почты и серверным компонентом 502 электронной почты. Как клиентский компонент 501 электронной почты, так и серверный компонент 502 электронной почты имеют буферы 503, 504, 505 и 506, которые предназначены для связи и размер которых фиксирован. Буферы 503, 504, 505 и 506 являются резервированными областями запоминающего устройства, предназначенными для промежуточного сохранения данных. Клиентский компонент 501 электронной почты начинает цикл «запрос-ответ» с заполнения буфера 503 одним или более подзапросами или удаленными операциями (УОП) до передачи содержимого из буфера 503 в буфер 504.

После того как осуществлен прием в буфер 504, каждую УОП по очереди обрабатывают серверным компонентом 502 электронной почты и соответствующий результат записывают в буфер 505. Каждая УОП производит некоторый результат. Результат может включать в себя данные, запрошенные клиентским компонентом 501 электронной почты, например конкретный набор сообщений электронной почты. Серверный компонент 502 электронной почты управляет буфером 505, и когда буфер близок к полному заполнению (например, осталось менее 8КБ), то серверный компонент 502 электронной почты записывает какие-либо необработанные УОП в конец буфера 505 и передает буфер 505 в буфер 506. Клиентский компонент 501 электронной почты затем начинает новый цикл «запрос-ответ» с записи необработанных УОП в буфер 503 для повторной передачи к серверному компоненту 502, когда буфер 503 вновь станет полным.

Размер ответа обычно бывает в среднем большим, чем размер запроса. По этой причине размер предназначенных для ответа буферов 505 и 506 обычно выполнен большим, чем размер предназначенных для запроса буферов 503 и 504. В одном варианте осуществления настоящего изобретения оптимальным размером буферов 505 и 506, предназначенных для ответа, был определен 96 кБ при размере 32 кБ буферов 503 и 504, предназначенных для запроса, т.е. в отношении 3 к 1. В одном варианте осуществления клиентский компонент электронной почты имеет возможность настройки размера любого из буферов 503, 504, 505 и 506.

Некоторые сети электронной почты, которые используют буферы, например сеть, показанная на Фиг.5, могут применять режим быстрой передачи между клиентским компонентом электронной почты и серверным компонентом электронной почты. Режим быстрой передачи включает в себя осуществляемые клиентом запросы такие, как, например, УОП, и которые разделяют по меньшей мере на два вида: на запросы, которые приводят к инициализации на сервере источника данных быстрой передачи, и на запросы, которые приводят к эффективной передаче данных от источника данных быстрой передачи к клиенту. Источником данных быстрой передачи может быть, например, таблица базы данных. Источник данных быстрой передачи служит в качестве готового (к работе) временного хранилища данных, которое позволяет последующим запросам к данным быть обслуженными с меньшими задержками, чем было бы возможно в ином случае. В некоторых случаях второй вид запроса режима быстрой передачи осуществляет поиск для того, чтобы достичь эффективной передачи данных посредством явного указания размера ответа, например размер ответа может быть установлен равным размеру всего клиентского буфера приема, уменьшая накладные расходы ответа.

На Фиг.6 показана операция быстрой передачи, имеющая, по меньшей мере, два цикла «запрос-ответ». В первом запросе 601 УОП (например, FXPrepare («Подготовить»)) инициализирует на сервере 502 источник данных быстрой передачи. На сервере обрабатывают только FXPrepare (т.е. источник данных быстрой передачи инициализирован) и ее результат возвращают в первом ответе 602. Во втором запросе 603 УОП (например, FXGetBuffer («Получить Буфер»)) осуществляет запрос к серверу на заполнение буфера 505 из «быстрого» источника данных. Сервер опорожняет «быстрый» источник данных в буфер и возвращает результат во втором ответе 604. Если выходной буфер 505 для серверного компонента электронной почты заполнен прежде, чем опорожнен «быстрый» источник, то могут быть необходимы дополнительные УОП «FXGetBuffer».

На Фиг.6 показана операция быстрой передачи, имеющая только один цикл «запрос-ответ». В первом запросе 605 серверный компонент 502 электронной почты обрабатывает как FXPrepare, так и FXGetBuffer, и результаты обеих операций возвращает в первом ответе 606. Результат FXPrepare доступен FXGetBuffer на серверном компоненте 502 электронной почты, поскольку часть буфера 503, 504, 505 и 506 определена явным образом как совместно используемая таблица данных. Желательно сокращение количества циклов «запрос-ответ», поскольку это приводит к более эффективной передаче данных. Операция быстрой передачи, имеющая более чем один цикл «запрос-ответ», может происходить в том случае, когда буфер 505 слишком полон для того, чтобы сохранить результат УОП FXGetBuffer.

Будет оценено, что УОП, показанные на Фиг.6А и 6В и на подобных фигурах в пределах (изложения) настоящей заявки, являются схематическими в том смысле, что могут быть реализованы практически посредством последовательностей УОП, если конкретно не указано иное.

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

В соответствии с одним аспектом настоящего изобретения количество циклов «запрос-ответ» минимизируют автоматически посредством указания того, что ключевые УОП (например, FXGetBuffer) освобождены от требования предсказания размера их результата. Вместо этого такие УОП обрабатывают серверным компонентом 502 электронной почты до тех пор, пока не достигнуто ограничение буфера 505 (который является таким же, как и буфер 506).

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

	УОП, которая может быть использована протоколом для обмена информацией с серверами предшествующих версий	УОП, которая может быть использована протоколом для обмена информацией с серверами наиболее недавней версии
ИД (ID) УОП	FXGetBuffer	FXGetBuffer
Параметры, используемые в множественных режимах	Требуемый размер: размер, который сервер должен резервировать в своем выходном буфере	Требуемый размер: установлен равным значению, превосходящему
		максимальное, ожидаемое предшествующими версиями, например, равным значению более 32 кБ. Это сигнализирует серверу о поиске нового параметра предельного размера
Новые параметры	Не доступны	Предельный размер: информирует сервер о верхнем пределе, до которого сервер может заполнять свой выходной буфер

УОП для серверных компонентов предшествующей версии сходны по построению с существующими УОП предшествующего уровня техники. То есть УОП предсказывают и определяют размер выходного буфера (например, буфера 505 (для) посылки), который должен быть резервирован для сохранения ответа. В отличие от этого, определяемый размер выходного буфера в наиболее недавней версии серверного компонента не предсказывают, а вместо этого устанавливают равным значению, превосходящему максимальное, ожидаемое серверными компонентами предшествующих версий, например равным значению более 32 кБ. Тот факт, что размер выходного буфера определяют превосходящим значение, ожидаемое серверными компонентами, дает сигнал серверному компоненту о поиске нового параметра предельного размера, которым может быть, например, заполнение выходного буфера для серверного компонента. Такие характеристики автоматически минимизируют количество циклов «запрос-ответ», только с небольшим увеличением сложности серверного компонента электронной почты, обрабатывающего УОП.

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

В сети электронной почты одной из обычных обязанностей протокола является достижение передачи объектов данных, например сообщений электронной почты, между клиентскими компонентами электронной почты и серверными компонентами электронной почты. Последующие примеры таких объектов данных включают в себя папки электронной почты, которые могут содержать сообщения электронной почты и другие объекты данных, и объекты данных для ассоциированной с папкой информации (АПИ, FAI), которые могут, например, содержать правила для обработки сообщений электронной почты или определять, как будут визуально воспроизведены объекты данных, которые папка содержит. Объекты данных могут быть «непрозрачными» для клиентского компонента электронной почты; то есть клиентский компонент электронной почты может не иметь средств для интерпретации содержимого объекта данных. В качестве альтернативы, объекты данных могут быть составлены из именованных свойств, например сообщение электронной почты может содержать свойства, именованные как «to» (конечный получатель), «from» (отправитель), «subject» (предмет), «importance» (важность), «body 1» (блок 1), «body 2», «body 3», «attachment 1» (вложение), «attachment 2» и так далее.

Одним достоинством сетей электронной почты, в которых объекты данных могут быть составлены из именованных свойств, по сравнению с сетями электронной почты, в которых объекты данных «непрозрачны», является возможность повышения производительности протокола в силу способности протокола передавать только часть объекта данных. Наличие именованных свойств разрешает конкретным свойствам объекта данных быть переданными без передачи объекта данных полностью.

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

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

Традиционные среды электронной почты, относящиеся к предшествующему уровню техники, используют объекты данных, которые могут быть составлены из именованных свойств, например сообщение электронной почты, которое может включать в себя набор именованных свойств для заголовка и набор именованных свойств для (текстового) блока, так что эти два набора могут быть запрашиваемы и/или обрабатываемы отдельно. Другим примером из предшествующего уровня техники является сообщение электронной почты, в котором набор именованных свойств для (текстового) блока включает в себя множественные версии (текстового) блока сообщения электронной почты, например в множественных форматах сообщений электронной почты, таких как простой текст, язык разметки гипертекста (ЯРГТ, HTML), расширенный текстовый формат (РТФ, RTF) и так далее. В такой ситуации серверные компоненты электронной почты предшествующего уровня техники могут несколькими способами отвечать на соответствующий протоколу запрос (текстового) блока сообщения электронной почты. Меньший ответ с наименьшей сложностью может быть посылка всех версий текстового блока сообщения электронной почты, но такой ответ может приводить к повышенному использованию полосы частот.

На Фиг.7А изображена часть процедуры, которую использует серверный компонент электронной почты предшествующей (предшествующего уровня техники) версии для ответа в такой ситуации. На этапе 701 серверный компонент электронной почты анализирует формат каждого текстового блока сообщения электронной почты. Если один из форматов является предварительно определенным стандартным форматом (например, RTF), то в процедуре осуществляют переход к этапу 703 и текстовый блок сообщения электронной почты, имеющий стандартный формат, посылают запрашивающему клиентскому компоненту электронной почты. Если ни один из форматов не является предварительно определенным стандартным форматом, то осуществляют переход от этапа 701 к этапу 702, на котором одну из версий текстового блока электронной почты преобразуют к стандартному формату. Подпроцедура, изображенная на Фиг.7А, также может быть использована тогда, когда существует только одна версия текстового блока сообщения электронной почты, но текстовый блок сообщения электронной почты может быть не в стандартном формате, который требует протокол.

На Фиг.7В изображена часть процедуры, которую использует серверный компонент электронной почты наиболее недавней версии в соответствии с настоящим изобретением. На этапе 704 запрос по протоколу, который приводит к использованию серверным компонентом электронной почты этой подпроцедуры, анализируют на наличие флажкового индикатора «BEST_BODY» («наилучший текстовый блок»). Флажковый индикатор в настоящем примере и другие флажковые индикаторы, используемые в настоящем документе, применяют для серверного компонента электронной почты для указания того, что клиентский компонент электронной почты соответствует наиболее недавней версии и требует применения функции, ассоциированной с флажковым индикатором. Могут быть использованы другие обозначения. Например, функция может быть применена по умолчанию, если обнаружен клиентский компонент электронной почты наиболее недавней версии.

В любом случае, если флажковый индикатор BEST_BODY не найден, осуществляют переход от этапа 704 к этапу 701 и продолжают работу, как описано со ссылкой на Фиг.7А.

Если флажковый индикатор найден, то в процедуре осуществляют переход к этапу 705, на котором выбирают наилучший текстовый блок сообщения электронной почты для посылки к запрашивающему клиентскому компоненту электронной почты. Если существует только один текстовый блок сообщения электронной почты, ассоциированный с запрошенным сообщением электронной почты, то он является наилучшим. Если доступны несколько текстовых блоков сообщения электронной почты, например, с различными форматами, то серверный компонент электронной почты выбирает наилучший из них в соответствии с, например, предварительно определенным ранжированием форматов текстовых блоков сообщений электронной почты (например, RTF, HTML, простой текст). Затем процесс осуществляет переход к этапу 703, на котором выбранный текстовый блок сообщения электронной почты посылают клиентскому компоненту электронной почты. В рассматриваемом варианте осуществления клиентский компонент электронной почты может быть способным к визуальному воспроизведению множества форматов текстовых блоков сообщений электронной почты, освобождая, таким образом, серверный компонент электронной почты от требования преобразования текстовых блоков сообщений электронной почты к стандартному формату. В дополнение, если необходимо, то клиентский компонент электронной почты может преобразовывать наилучший текстовый блок сообщения электронной почты к другому формату.

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

УОП могут быть использованы для обеспечения дублирования папки электронной почты между серверным компонентом электронной почты и клиентским компонентом электронной почты. Запрос на синхронизацию папки может быть сделан, например, посредством УОП SynchFolder («Синхронизировать папку»). Если клиентский компонент электронной почты способен визуально воспроизводить нестандартные форматы текстовых блоков сообщений электронной почты, то он может установить флажковый индикатор BEST_BODY в УОП SynchFolder для указания того, что серверный компонент электронной почты может выбирать наилучший формат из доступных текстовых блоков сообщений электронной почты, нежели запрашивать сервер о возвращении текстового блока сообщения электронной почты в стандартном формате. Серверный компонент электронной почты может должным образом обрабатывать УОП, как имеющие, так и не имеющие флажковый индикатор BEST_BODY, лишь при умеренном увеличении сложности. УОП для обмена информацией с серверами предшествующей версии и наиболее недавней версии может включать в себя, например, характеристики, приведенные в таблице ниже:

	УОП, которая может быть использована протоколом для обмена информацией с серверами предшествующей версии	УОП, которая может быть использована протоколом для обмена информацией с серверами наиболее недавней версии
ИД УОП	SynchFolder	SynchFolder
Новые параметры	Не доступно	Флажковый индикатор «наилучший текстовый блок»: если установлен, то серверный компонент электронной почты выбирает наилучший текстовый блок сообщения электронной почты для посылки клиентскому компоненту электронной почты. Преобразование текстового блока сообщения электронной почты к предварительно определенному стандартному формату, если необходимо

На Фиг.8А-8С показаны различные существующие режимы передач набора сообщений электронной почты между серверным компонентом электронной почты и клиентским компонентом электронной почты. Для каждого режима каждое сообщение электронной почты имеет именованные свойства, включающие в себя набор для заголовков и набор для текстовых блоков, и папка содержит несколько сообщений электронной почты. На Фиг.8А проиллюстрирован режим передачи объекта полностью. На чертеже показаны передача заголовка 801 первого сообщения электронной почты и затем текстового блока 802 первого сообщения электронной почты прежде заголовка 803 второго сообщения электронной почты и затем текстового блока 804 второго сообщения электронной почты и так далее до тех пор, пока не будет передан набор сообщений электронной почты. На Фиг.8В проиллюстрирован режим передачи «сначала заголовки». В этом режиме передают заголовок 805 первого сообщения электронной почты и затем заголовок 806 второго сообщения электронной почты и так далее, пока не будут переданы все заголовки, и только затем передают текстовый блок 807 первого сообщения электронной почты и затем текстовый блок 808 второго сообщения электронной почты и так далее, пока не будет передан набор сообщений электронной почты. На Фиг.8С проиллюстрирован режим передачи «только заголовки». Как и показывает название, передают только заголовки 809 сообщений электронной почты в ответ на запрос на передачу набора сообщений электронной почты. Текстовые блоки 810 сообщений электронной почты будут переданы только в ответ на дополнительный явный запрос. В любом из этих режимов последовательность передачи может быть временно прервана имеющим более высокий приоритет запросом от клиентского компонента электронной почты, например, для конкретного текстового блока сообщения электронной почты.

Папка электронной почты является примером целевого назначения для запроса на передачу набора сообщений электронной почты. Однако папка электронной почты может содержать объекты данных, отличные от сообщений электронной почты. Как было рассмотрено выше, режимы передачи часто определяют со ссылкой на заголовки сообщений электронной почты и на текстовые блоки сообщений электронной почты такие, как режимы передачи «сначала заголовки» и «только заголовки». В таких режимах передачи попытка передачи объектов данных, для которых набор именованных свойств для заголовков и/или набор именованных свойств для текстовых блоков могут не быть строго определены, может привести к отказу, или фатальной ошибке, в работе протокола. Один аспект настоящего изобретения предотвращает такую ситуацию обеспечением того, что объекты данных, для которых набор именованных свойств для заголовков и/или набор именованных свойств для текстовых блоков не является строго определенным, всегда могут быть переданы полностью, а не частично. Такой вариант осуществления может быть иллюстрирован примером согласно Фиг.8D. По этому примеру передача между клиентским компонентом электронной почты и серверным компонентом электронной почты может происходить лишь в режиме «только заголовки». Соответственно, передают заголовок 811 первого сообщения электронной почты и затем объект 812 данных становится следующим кандидатом на передачу. Набор именованных свойств для заголовков не является строго определенным для объекта 812 данных такого, как АПИ, поэтому передают объект данных полностью. Следующий кандидат на передачу имеет строго определенный набор именованных свойств для заголовка (т.е. объект данных, являющийся кандидатом, обладает всеми именованными свойствами, определенными явным образом клиентским компонентом электронной почты в качестве принадлежащих набору именованных свойств для заголовка), и поэтому передают только заголовок 813 сообщения электронной почты.

Примером одного способа реализации этого аспекта настоящего изобретения является использование флажкового индикатора такого, как IGNORE_MODE_ON_FAI («Игнорировать режим для АПИ»), который может быть включен в состав УОП, предназначенной для синхронизации, такой как УОП SynchFolder, описанная выше. Серверный компонент электронной почты может должным образом обрабатывать УОП, как имеющие, так и не имеющие флажковый индикатор IGNORE_MODE_ON_FAI, при лишь умеренном увеличении сложности. УОП могут включать в себя характеристики, приведенные в таблице ниже, для обеспечения дублирования папки электронной почты между серверным компонентом электронной почты и клиентским компонентом электронной почты:

	УОП, которая может быть использована протоколом для обмена информацией с серверами предшествующей версии	УОП, которая может быть использована протоколом для обмена информацией с серверами наиболее недавней версии
ИД УОП	SynchFolder	SynchFolder
Новые параметры	Не доступно	Флажковый индикатор «Игнорировать режим для АПИ»: если установлен, то объекты данных такие, как АПИ, которые не имеют строго определенного набора именованных свойств для заголовка и/или текстового блока, серверный компонент электронной почты может ответить на запрос на передачу объектом данных полностью, вне зависимости от преобладающего режима передачи

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

На Фиг.9 показано, что даже пример простой стратегии домашнего сервера может иметь сложности. В примере, показанном на Фиг.9, конкретный серверный компонент 901 электронной почты первоначально обозначен как домашний сервер для конкретного пользователя сети электронной почты. Через некоторое время указанный в качестве пункта назначения домашний сервер пользователя заменяют на другие серверные компоненты (903 и 905) электронной почты, обычно по причинам администрирования. Серверные компоненты (901, 903 и 905) электронной почты могут быть, например, физически отличающимися, или логически отличающимися, или быть отличающимися по версиям. Клиентский компонент 902 электронной почты может обмениваться информацией только с серверным компонентом 901 электронной почты от момента времени Т₀ до момента времени Т₁, затем клиентский компонент 904 электронной почты может обмениваться информацией до момента времени Т₂ только с серверным компонентом 903 электронной почты, и затем клиентский компонент 906 электронной почты может обмениваться информацией только с серверным компонентом 905. Клиентские компоненты 902, 904 и 906 электронной почты могут быть одинаковыми или отличающимися. Серверные компоненты 901 и 903 электронной почты могут или не могут существовать после времени Т₂. Такие сложности конкретно имеют отношение к обсуждаемому далее дублированию хранилища сообщений электронной почты.

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

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

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

На Фиг.10 показан более подробный пример протокола, который предусматривает пошаговое дублирование. Хранилище сообщений электронной почты может быть подразделено на папки для электронной почты. Каждая папка электронной почты может быть дублирована независимо от остальных, обеспечивая более точное управление процессом дублирования. В приведенном примере процесс пошагового дублирования назван синхронизацией, поскольку он включает в себя распространение изменений от клиентского компонента 501 электронной почты к серверному компоненту 502 электронной почты, так же как и от серверного компонента 502 электронной почты к клиентскому компоненту 501 электронной почты. Вслед за запросом 1001 на синхронизацию серверный компонент 502 электронной почты обрабатывает УОП SynchFolder. УОП включает в себя параметр folderID (идентификатор папки) (не показан) и параметр stateblob₀ (состояние большого двоичного объекта). Параметр folderID идентифицирует папку электронной почты, которая является целью (назначением) запроса 1001 на синхронизацию. Параметр stateblob₀ содержит информацию, которая позволяет серверному компоненту 502 электронной почты определять, какие изменения, если они были, произошли в папке электронной почты после того, как она была последний раз синхронизована. Если запрос 1001 представляет собой запрос на синхронизацию целевой папки, впервые осуществляемый клиентским компонентом 501 электронной почты, то серверный компонент 502 электронной почты определяет, изменилась ли целевая папка электронной почты в хранилище сообщений электронной почты по сравнению с пустой папкой. В ответе 1002 на запрос 1001 серверный компонент 502 электронной почты посылает любые изменения клиентскому компоненту 501 электронной почты, включающие в себя любые сообщения электронной почты и/или другие объекты данных, которые были добавлены к целевой папке, и перечень любых сообщений электронной почты и/или другие объекты данных, которые были удалены из целевой папки. Серверный компонент 502 электронной почты создает также новый stateblob₁, представляющий состояние целевой папки таким, каким оно будет на клиентском компоненте 501 электронной почты непосредственно после синхронизации, и также посылает этот stateblob₁ в ответе 1002. Когда серверный клиентский компонент 501 электронной почты посылает следующий запрос 1003 на синхронизацию той же папки, что и в запросе 1001, то запрос 1003 будет включать в себя в качестве параметра тот же stateblob₁, который был возвращен в ответе 1002. Как и ранее, серверный компонент 502 электронной почты будет использовать информацию, содержащуюся в stateblob₁, для определения того, какие изменения, если были, произошли в целевой папке, и посылает эти изменения вместе с созданным заново stateblob₂ обратно к клиентскому компоненту 501 электронной почты в ответе 1004.

Если объект «stateblob» является значительным по размеру, то он может отрицательно воздействовать на производительность протокола, поскольку его посылают к серверному компоненту электронной почты и от серверного компонента электронной почты при, например, каждом запросе на синхронизацию папки электронной почты. В некоторых сетевых протоколах электронной почты, которые предусматривают синхронизацию папок электронной почты, объект «stateblob» может большей частью быть составлен из набора объектов данных «changeID» для сообщений, которые идентифицируют изменения в сообщениях электронной почты, которые были видимы клиентским компонентом электронной почты. Можно сказать, что изменение сообщения электронной почты должно быть видимым клиентским и/или серверным компонентом электронной почты, когда измененное сообщение электронной почты передают этому компоненту.

Одной целью объекта данных «changeID» для сообщения может быть идентификация уникальным образом изменения в сообщении электронной почты относительно контекста сети электронной почты в целом. В сети электронной почты, которая применяет стратегию домашнего сервера, пользовательский домашний сервер может быть ответственен за ассоциацию объекта данных «changeID» для сообщения с ранее не видимым изменением сообщения электронной почты. Например, домашний сервер может применять объекты данных «changeID» для сообщения, содержащие объект данных «serverID» и порядковый номер. Объект данных «serverID» может уникально идентифицировать серверный компонент электронной почты в контексте сети электронной почты в целом, используя известные способы такие, как глобальные уникальные идентификаторы. Если такие идентификаторы сами являются значительными по размеру, то вместо них объект данных «serverID» может быть индексом в таблице идентификаторов, поддерживаемой серверным компонентом электронной почты. Порядковый номер может быть обеспечен счетчиком, например, имеющим размер 6 байтов, локальным для серверного компонента электронной почты и увеличиваемым при получении серверным компонентом электронной почты не видимого ранее сообщения электронной почты для сохранения.

Для целей обсуждения объект данных «changeID сообщения» может быть представлен посредством, например, «S₁:1», при этом S₁ представляет объект данных «serverID» для первого компонента электронной почты и «1» представляет порядковый номер. Набор объектов данных «changeID сообщения» может быть представлен, например, «S₁:1, S₁:2, S₁:3», при этом «S₁:1», «S₁:2» и «S₁:3» являются последовательными объектами данных «changeID сообщения», примененными серверным компонентом электронной почты с S₁ в качестве «serverID».

Если создают объект «stateblob» по большей части из набора объектов данных «changeID сообщения», представляющих сообщения об изменениях электронной почты, видимых клиентским компонентом электронной почты (набор «видимые изменения сообщений»), то были разработаны некоторые способы для кодирования набора с целью уменьшения его размера, например «S₁:1, S₁:2, S₁:3, S₁:4» может быть кодировано как «S₁:1-4». В дополнение, серверный компонент электронной почты может гарантировать, что порядковые номера, которые он использует, являются всегда возрастающими. В таком случае не являющийся непрерывным (по значениям) набор «видимые изменения сообщений»), например, «S₁:1, S₁:3, S₁:5, S₁:7» может быть кодирован как «S₁:1-7», то есть как диапазон значений, включающий в состав минимальный и максимальный порядковые номера, без потери функциональности.

В сценарии, изображенном на Фиг.9, набор («видимые изменения сообщений») может включать в себя объекты данных «changeID сообщения», которые были созданы серверными компонентами электронной почты (например, S₁, S₂), отличными от текущего домашнего сервера (например, S₃). Объект данных «changeID сообщения», созданный текущим домашним сервером, может быть обозначен как собственный (внутренний) «changeID сообщения», объект данных «changeID сообщения», созданный другими серверными компонентами электронной почты, может быть обозначен как внешний «changeID сообщения». Сетевые протоколы электронной почты для обмена информацией с серверными компонентами электронной почты, относящимися к предшествующей версии, не предусмотрены для оптимизации не являющихся непрерывными последовательностей (объектов) внешних «changeID сообщения» как диапазона, включающего в себя минимальный и максимальный порядковые номера, на основе «в расчете на один серверный компонент электронной почты». В нижеследующей таблице показано преимущество включения такой оптимизации в состав варианта осуществления настоящего изобретения:

	Оптимизация, используемая предшествующей версией сервера (текущий домашний сервер S3)	Оптимизация, используемая наиболее недавней версией сервера (текущий домашний сервер S3)
Набор («видимые изменения сообщений») до оптимизации	S1:1, S1:3, S1:5, S1:7 S2:1, S2:3, S2:5, S2:7 S3:1, S3:3, S3:5, S3:7
Набор («видимые изменения сообщений») после оптимизации	S1:1, S1:3, S1:5, S1:7 S2:1, S2:3, S2:5, S2:7 S3:1-7	S1:1-7 S2:1-7 S3:1-7

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

	Результат УОП, который может быть использован протоколом при обмене информацией с серверами предшествующей версии	Результат УОП, который может быть использован протоколом при обмене информацией с серверами наиболее недавней версии
УОП ИД	SynchFolder	SynchFolder
Неизмененные параметры, используемые в новом режиме	«stateblob»: оптимизация, которая не включает в себя не являющиеся непрерывными наборы объектов данных внешние «changeID сообщения»	«stateblob»: усовершенствованная оптимизация, которая включает в себя не являющиеся непрерывными наборы объектов данных внешние «changeID сообщения»

На Фиг.11А и Фиг.11В показано различие между подпроцедурами, которые могут быть использованы соответственно сервером предшествующей версии и сервером наиболее недавней версии, по отношению к УОП SynchFolder. На Фиг.11А показаны этапы 1101, 1102 и 1103. На этапе 1101 создают начальный набор «видимые изменения сообщений». На этапе 1102 оптимизируют элементы набора «видимые изменения сообщений», которые являются внутренними объектами данных «changeID сообщения». На этапе 1103 оптимизированный набор «видимые изменения сообщений» добавляют к объекту данных «stateblob», который может быть послан с ответом на запрос клиентскому компоненту электронной почты, который затребовал синхронизацию. На Фиг.11В включен дополнительный этап 1104, который показывает элементы набора «видимые изменения сообщений», которые являются внешними объектами данных «changeID сообщения» и которые, будучи оптимизированными прежде набора «видимые изменения сообщений», теперь с применением усовершенствованной оптимизации, также добавляют к объекту данных «stateblob» на этапе 1103.

Несмотря на то, что разбиение хранилища сообщений электронной почты на папки электронной почты предусмотрено для более «мелкоструктурного» управления процессом синхронизации, оно автоматически не обеспечивает повышение производительности протокола и может привести к снижению производительности протокола. Например, некоторые протоколы требуют, чтобы каждая папка хранилища сообщений была синхронизирована отдельно. Каждая операция синхронизации обычно имеет некоторые накладные расходы, и такие накладные расходы могут быть значительными. Операции синхронизации, использующие объекты данных «stateblob», являются примерами операций, которые могут иметь значительные потери. В случае синхронизации всего хранилища сообщений протоколы, которые требуют, чтобы каждая папка хранилища сообщений была синхронизирована отдельно, могут быть в невыгодном положении по сравнению с протоколами, которые требуют меньшее количество операций синхронизации.

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

Если хранилища сообщений электронной почты подразделены на папки электронной почты, то папки электронной почты могут быть организованы в иерархическую структуру. На Фиг.12 показан пример иерархии папок электронной почты. На Фиг.12 папка 1204 является вложенной папкой (подпапкой) папки 1203. Папка 1203, в свою очередь, является вложенной папкой папки 1202. Папка 1201 является корневой папкой. Корневая папка не является вложенной папкой для какой-либо другой папки. Все другие папки являются элементами иерархии папок, имеющей корнем папку 1201. Обычно каждая папка в иерархии папок не имеет непосредственной, или прямой, ссылки на каждую из других папок. Папка может иметь непосредственную ссылку на свои вложенные папки. Папка может также иметь непосредственную ссылку на любую из папок, для которых она является вложенной папкой. Во многих случаях может иметь место, что только одна папка, для которой каждая папка имеет непосредственную ссылку, является корневой папкой иерархии.

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

Имя атрибута	Тип атрибута	Примечания
ИД папки	FID	Тип FID содержит глобальный уникальный идентификатор (GUID) и шестибайтовый порядковый номер. Это значение может быть использовано, чтобы однозначно определить папку электронной почты в контексте сети электронной почты
PR_LOCAL_COMMIT_TIME_MAX	Timestamp	Эту временную метку корректируют всякий раз, когда изменяют содержимое папки
PR_DELETED_COUNT_TOTAL	QWORD	Это значение является счетчиком общего количества элементов, когда-либо удаленных из папки

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

Обмен информацией между клиентским компонентом электронной почты и серверным компонентом электронной почты может быть подразделен на сеансы связи. Потеря синхронизации хранилища сообщений электронной почты может происходить между сеансами, например, в течение прерывания сетевого соединения. Для того, чтобы повторно установить синхронизацию хранилища сообщений электронной почты в начале сеанса связи, некоторые протоколы с целью обмена информацией с серверными компонентами электронной почты, относящимися к предшествующей версии, применяли УОП SynchFolder для каждой папки в иерархии папок. Обычно содержимое некоторых папок не будет изменено между сеансами. УОП SynchFolder с неизмененной папкой в качестве цели операции приводит к результату «null synch» («нет синхронизации»). Несмотря на то, что «null synch» не приводит к тому, что любые изменения папки передают клиентскому компоненту электронной почты, все же имеются накладные расходы, связанные с этим, например объект данных «stateblob», который может быть значительным.

На Фиг.13 иллюстрирован вариант осуществления изобретения, который предотвращает такие результаты «null synch» посредством использования таблицы глубокой иерархии. В первом запросе 1301 клиентский компонент 501 электронной почты посылает УОП (например, GetHierarchyTable («Получить таблицу иерархии»)), запрашивающую таблицу глубокой иерархии, к серверному компоненту 502 электронной почты. В первом ответе 1302 копию таблицы глубокой иерархии поставляют клиентскому компоненту 501 электронной почты. Обычно клиентский компонент 501 электронной почты будет иметь предшествующую копию таблицы глубокой иерархии. Клиентский компонент 501 электронной почты может быстро определить, какие папки изменены в пользовательском хранилище сообщений электронной почты, находящемся на серверном компоненте 502 электронной почты, используя сравнение двух копий по строкам. Затем применяют УОП (например, SynchFolder), чтобы синхронизировать только те папки, которые были изменены. Запрос 1303 и ответ 1304 могут быть повторены, как требуется для синхронизации измененных папок. После успешной синхронизации копию таблицы глубокой иерархии и относящейся к клиентскому компоненту электронной почты можно обновлять для согласования с самой последней копией, которая была послана в ответе 1302. Если клиентский компонент 501 электронной почты не имеет предшествующей копии таблицы глубокой иерархии, то все папки, которые имеют строку в самой последней копии, могут быть синхронизированы. Как только была установлена синхронизация пользовательского хранилища сообщений электронной почты, то синхронизация может быть поддерживаема периодическим повторением начала этапов сеанса, описанных выше (т.е. опросом серверного компонента электронной почты), но такая схема имеет недостатки. Например, интервал опроса может быть значительно короче, чем интервал между изменениями в пользовательском хранилище сообщений электронной почты. В таком случае относительно много сравнений таблиц глубокой иерархии будут указывать, что никакие папки не изменены. Такие сравнения являются, в действительности, впустую затраченными усилиями, так что протокол, который способен избегать их, может быть более эффективным.

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

С последующей ссылкой на Фиг.13, на которой наиболее недавняя версия клиентского компонента 501 электронной почты в соответствии с аспектом настоящего изобретения применяет УОП GetHierarchyTable, в первом запрос 1301 в начале сеанса связи с серверным компонентом 502 электронной почты клиентский компонент 501 электронной почты автоматически подписывают на уведомления об изменениях, ассоциированных с таблицей глубокой иерархии, которую возвращают в ответе 1302. Когда изменение происходит в папке электронной почты в пользовательском хранилище сообщений электронной почты, находящемся на клиентском компоненте электронной почты, например сообщение электронной почты добавляют к папке, таблицу глубокой иерархии также обновляют, как описано ранее. Изменение в таблице глубокой иерархии запускает уведомляющее предупреждение 1305 (к) клиентскому компоненту 501 электронной почты. Несмотря на то, что уведомляющее предупреждение находится в ответе на подписку, устанавливаемую запросом 1301, оно не является частью явного цикла «запрос-ответ». Таким образом, использование системы уведомления, как предусмотрено настоящим изобретением, приводит к значительно меньшим накладным расходам для сети электронной почты.

Единственная подписка может приводить ко многим уведомлениям. В одном варианте осуществления предупреждение доставляют с использованием сетевого транспортного механизма без установления соединения, например, по Протоколу дейтаграмм пользователя/Интернет протоколу (ПДП/ИП, UDP/IP), но может быть использован любой подходящий сетевой транспортный механизм. В ответ на предупреждение клиентский компонент 501 электронной почты посылает запрос 1306, содержащий УОП (например, GetNotification («Получить уведомление»)), (к) серверному компоненту 502 электронной почты. В ответе 1307 все измененные строки таблицы глубокой иерархии (т.е. строки, соответствующие измененной папке, которая осуществила запуск уведомления) посылают к клиентскому компоненту 501 электронной почты. Затем клиентский компонент 501 электронной почты применяет УОП (например, SynchFolder), чтобы синхронизировать только те папки, которые были изменены.

Множественные клиентские компоненты электронной почты могут быть подписаны на уведомления об изменениях, ассоциированных с одним объектом данных (например, одной папкой электронной почты), например, для обеспечения функциональной возможности совместной работы. Как проиллюстрировано на Фиг.18, клиентские компоненты 1801, 1802 и 1803 электронной почты подписаны на уведомления об изменениях, ассоциированных с одним объектом данных (не показан), размещенным на серверном компоненте 1804 электронной почты. Клиентский компонент 1803 электронной почты посылает УОП 1805 в серверному компоненту 1804 электронной почты, что приводит к изменению в объекте данных. В качестве результата изменения серверный компонент 1804 электронной почты посылает уведомления 1806, 1807 и 1808 об изменениях к клиентским компонентам 1801, 1802 и 1803 электронной почты. Уведомления об изменениях могут нести мало информации помимо идентификации объекта данных, который был изменен, так что, например, для клиентского компонента электронной почты может не быть способа для определения, что было причиной конкретного изменения. Если объектом данных является, например, папка электронной почты, то уведомления 1806, 1807 и 1808 об изменениях могут привести к инициации каждым клиентским компонентом 1801, 1802 и 1803 электронной почты (выполнения) синхронизации для измененной папки. Поскольку клиентский компонент 1803 электронной почты был, в этом примере, ответственным за изменение, результатом будет «null synch».

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

На Фиг.19A изображено поведение уведомления, которое может быть обеспечено серверными компонентами электронной почты предшествующей версии. На Фиг.19B изображено настраиваемое поведение уведомления в соответствии с аспектом настоящего изобретения. Если требуется, то клиентский компонент электронной почты наиболее недавней версии может указать серверному компоненту электронной почты, что он способен к поддержке поведения уведомления согласно Фиг.19B, например, поставляя с запросом флажковый индикатор, в примере, показанном на Фиг.19B, IGNORE_OWN - флажковый индикатор.

На этапе 1901 выбирают следующего кандидата (возможного абонента) из набора абонентов, подлежащих уведомлению. На этапе 1904 подписку проверяют на наличие флажкового индикатора IGNORE_OWN. Если флажковый индикатор отсутствует, то от этапа 1904 переходят к этапу 1902, на котором уведомление посылают абоненту-кандидату. Если флажковый индикатор обнаружен, то от этапа 1904 переходят к этапу 1905, на котором подписку проверяют еще раз, чтобы определить, подписчик (абонент) ли осуществил запуск этого уведомления. Такое определение может быть сделано, например, посредством проверки идентификатора сеанса связи («ИД сеанса») для того сеанса, который был использован при размещении подписки. ИД сеанса, например, может содержать глобальный уникальный идентификатор и шестибайтовый порядковый номер. Уведомление также проверяют на наличие ИД сеанса, ассоциированного с его (уведомления) причиной. Если такие два (значения) совпадают, то уведомление запрещают. Результатом является то, что клиентский компонент электронной почты, который вызывал уведомление, также не будет получать такое уведомление. Затем подпрограмма приступает к этапу 1903, описанному ниже.

Если абонент не осуществил запуск уведомления, то ИД сеанса, ассоциированного с подпиской, не является тем же, что и ИД сеанса, ассоциированного с причиной уведомления, и от этапа 1905 переходят к этапу 1902, на котором посылают уведомление. Затем процесс переходит к этапу 1903, на котором осуществляют определение, есть ли еще абоненты, подлежащие уведомлению. Если есть, то подпрограмма осуществляет возврат к этапу 1901, иначе - данная подпрограмма завершена.

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

Обычно, когда сообщения или другие данные такие, как файлы, запрашивают для синхронизации или копирования, запрос (например, УОП) включает в себя указание всех сообщений, для которых синхронизация является требуемой. Такой перечень может быть создан автоматически серверным компонентом электронной почты, например, посредством использования свойства «stateblob», описанного выше. Для серверных компонентов электронной почты предшествующей версии (предшествующего уровня техники) ошибка в одном сообщении или объекте данных в запросе УОП вызовет отказ, или неуспешное завершение, всех элементов в запросе. Такой процесс показан на Фиг.14A, на которой запрос, содержащий УОП (например, FXPrepare («Подготовить»)), передают на этапе 1401 с набором идентификаторов сообщений (messageID), предназначенных для копирования или синхронизации. Механизм быстрой передачи настраивают (устанавливают) на серверном компоненте 502 электронной почты, и ИД быстрой передачи передают клиентскому компоненту 501 электронной почты на этапе 1402. Клиентский компонент 501 электронной почты затем запрашивает копирование или синхронизацию объектов данных через запрос, содержащий, например, УОП FXGetBuffer (этап 1403). Ошибка происходит с одним или более сообщениями или другими объектами данных тогда, когда серверный компонент 502 электронной почты осуществляет попытку открыть запрошенные сообщения. Примеры ошибок включают в себя подвергшиеся повреждению сообщение или объект данных, отказ сервера, нехватку памяти для серверного компонента 502 электронной почты или вирус, обнаруженный для объекта данных.

После ошибки серверный компонент 502 электронной почты посылает фатальную ошибку УОП в потоке данных, направленном к клиентскому компоненту 501 электронной почты, на этапе 1404. В таком случае синхронизация завершена неуспешно, сообщения внутри набора идентификаторов сообщений (messageID) не являются синхронизированными или скопированными, и «stateblob» или подобная информацию для обновления не принимается клиентским компонентом 501 электронной почты. Затем клиентский компонент 501 электронной почты вынужден запросить синхронизацию или копирование объектов данных в другое время. Возможно, что если ошибка не зафиксирована на серверном компоненте 502 электронной почты, то может быть продолжена посылка сообщений об ошибках, и сообщения из набора идентификаторов сообщений (messageID) могут быть никогда не синхронизированы или скопированы.

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

В качестве одного примера того, как обрабатывать относящуюся к объекту ошибку, серверный компонент электронной почты наиболее недавней версии может посылать сообщение об ошибке в потоке данных для объекта данных, имеющего ошибку объекта. В приведенном примере для простоты ссылки ошибка обозначена как FXErrorInfo («Информация об ошибке»). Если требуется, то как далее описано ниже, FXErrorInfo может включать в себя информацию такую, как, например, ИД сообщения для объекта данных, имеющего ошибку, и дополнительную информацию относительно того, почему сообщение завершено неуспешно.

На Фиг.14B показана синхронизация, в которой ошибка происходит в сообщении М₃. Ошибка приводит к ответу 1405 на FXGetBuffer, включающему в себя сообщение M₁, и сообщение M₂, за которым следует FXErrorInfo, и затем сообщение M₄. Информация FXErrorInfo позволяет клиентскому компоненту 501 электронной почты узнать, какое сообщение имело ошибку, и синхронизировать все остальные сообщения, находящиеся внутри ответа. Если сообщение FXErrorInfo об ошибке включает в себя информацию о причине ошибки, то на информацию может соответствующим образом воздействовать клиентский компонент, например, посредством визуального воспроизведения сообщения об ошибке для пользователя.

В последующей таблице показан пример формата, который может принимать FXErrorInfo:

FXErrorInfo
Имя атрибута	Тип атрибута	Примечания
Версия	WORD	Версия данной структуры
Код ошибки	DWORD
ИД сообщения	MID	Тип MID включает в себя глобальный уникальный идентификатор (GUID) и шестибайтовый порядковый номер. Он является ИД сообщения для сообщения, которое вызвало ошибку
		Здесь могут быть добавлены ноль или более атрибутов
Размер дополнительного поля	ULONG	Размер массива, следующего далее
Дополнительное поле	BYTE array	Неструктурированный массив для подробностей ошибок передачи сообщений

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

Информация FXErrorInfo разрешает завершить синхронизацию первого ответа, например, заканчиваясь тем, что «stateblob» или другую информацию поставляют клиентскому компоненту 501 электронной почты. Поскольку теперь клиентский компонент электронной почты синхронизирован через сообщение M₄, то следующий запрос 1406 на синхронизацию может привести к ответу 1407, имеющему сообщения после M₄ (например, M₅ и М₆).

Чтобы указать, что клиентский компонент 501 электронной почты является наиболее недавней версией и таким образом способен обрабатывать сообщение FXErrorInfo, может быть определен флажковый индикатор, например, FXRecoverMode («Режим восстановления»), который может быть передан с запросом УОП на синхронизацию или копирование. Могут быть использованы другие указания для клиентского компонента 501 электронной почты при обмене сообщениями с серверным компонентом 502 электронной почты, который способен обрабатывать сообщения FXErrorInfo.

Когда серверный компонент 502 электронной почты посылает одно или более сообщений или другие объекты данных клиентскому компоненту 501 электронной почты, поток данных к клиентскому компоненту 501 электронной почты может быть отделен или определен метками свойств (например, обозначенными «ptags») Например, перечень сообщений может включать в себя для каждого сообщения начальную (Start) метку свойства, или ptag, сообщения и конечную (End) метку свойства сообщения. Между начальной и конечной метками свойств могут быть метки для перечня (List) свойств и метка для темы (Subject), или предмета, которая может иметь свойство строки (string). За меткой темы может следовать собственно тема. Могут быть использованы другие метки свойств.

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

ptagMessageListStart

ptagMessageStart

ptagPropList

ptagSubject [PT_STRING]

«Комментарий: Ваша электронная почта»

...

ptagMessageEnd

ptagMessageStart

...

ptagFXErrorInfo [PT_BINARY]

[содержимое, как описано в таблице]

ptagMessageStart

...

ptagMessageEnd

ptagMessageListEnd

На Фиг.15A показаны этапы, которые серверный компонент 502 электронной почты может использовать для передачи сообщений к клиентскому компоненту 501 электронной почты предшествующей версии. Начиная от этапа 1501 подготавливают набор сообщений, например, посредством размещения набора сообщений в хранилище для быстрой передачи данных. На этапе 1502 начинают потоковый вывод сообщения, например, немедленно после того, как размещено в буфере посылки серверного компонента 502 электронной почты. Если происходит ошибка при потоковом выводе сообщения, то фатальную ошибку УОП направляют к клиентскому компоненту 501 электронной почты на этапе 1504. Затем подпрограмму завершают. Если при потоковом выводе сообщения ошибка не происходит, то на этапе 1503 определяют, есть ли еще сообщения в наборе. Если есть, то процесс возвращают обратно к этапу 1502, на котором потоком выводят следующее сообщение. Если сообщений нет, то подпрограмму завершают.

На Фиг.15B показана процедура для обработки набора сообщений, осуществляемая серверным компонентом 502 электронной почты наиболее недавней версии. Выбранные этапы различны в зависимости от того, относится ли клиентский компонент электронной почты к наиболее недавней версии или к предшествующей версии. Этапы 1501-1504 являются этапами, выбранными для клиентского компонента электронной почты предшествующей версии, и теми же, что и этапы, имеющие одинаковую нумерацию ссылок в предыдущем параграфе.

Если на этапе 1502 обнаруживают ошибку при потоковом выводе сообщения, то на этапе 1505 определяют, включен ли в состав запроса флажковый индикатор такой, как FXRecoverMode. Если запрос содержит флажковый индикатор, то клиентский компонент 501 электронной почты является наиболее недавней версией, и от этапа 1505 осуществляют переход к этапу 1506, на котором осуществляют потоковый вывод FXErrorInfo к клиентскому компоненту 501 электронной почты. Затем процесс может быть продолжен на этапе 1503. Если в состав запроса флажковый индикатор не включен, то от этапа 1505 осуществляют переход к этапу 1504, на котором потоком выводят фатальную ошибку УОП. Затем подпрограмму завершают.

Как видно, присутствие флажкового индикатора в запросе разрешает продолжение процесса потокового вывода FXErrorInfo вместо отказа и посылки фатальной ошибки УОП. Флажковый индикатор посылают посредством клиентского компонента 501 электронной почты наиболее недавней версии. Предшествующие версии клиентских компонентов электронной почты не применяют флажковый индикатор, и таким образом ошибка приводит к выводу фатальной ошибки УОП, как описано выше. Если требуется, в другом варианте осуществления сообщение об ошибке (например, FXErrorInfo) может быть послано для конкретных свойств сообщения или другого объекта данных вместо всего сообщения. Например, FXErrorInfo может быть послано для текстового блока сообщения или для вложения в сообщение. Клиентский компонент 501 электронной почты может затем синхронизировать или копировать свойства, которые успешно посланы без ошибки, и только свойства, имеющие ошибки, не синхронизируют и не копируют.

В некоторых случаях сообщение или другой объект данных могут быть достаточного размера, который охватывает ответы на множественные FXGetBuffer. Для обработки таких сообщений клиентский компонент 501 электронной почты может включать в себя логику «отката назад», так что может удалять любые полученные частично сообщения и затем осуществлять продолжение, чтобы правильно принимать дальнейшие сообщения после приема сообщения об ошибке.

Иногда для клиентского компонента электронной почты может потребоваться быть обеспеченным обратной связью относительно хода выполнения копирования или синхронизации объектов данных таких, как сообщения электронной почты. В соответствии с одним аспектом настоящего изобретения, клиентский компонент 501 электронной почты наиболее недавней версии может указать, что он способен обрабатывать режимы хода выполнения, например, посредством посылки флажкового индикатора такого, как PROGRESS_MODE, серверному компоненту 502 электронной почты при запросе на синхронизацию или на копирование объектов данных. В ответе серверный компонент 502 электронной почты наиболее недавней версии может послать различную информацию вместе с сообщениями, как, например, общий размер всех сообщений, суммарное количество сообщений и общий размер каждого из сообщений или произвольную комбинацию перечисленного.

Например, как показано на Фиг.16A, для предшествующей версии клиентского компонента 501 электронной почты в ответ на запрос (1601 и 1603) быстрой передачи набора сообщений клиентский компонент 501 электронной почты принимает сообщения. На Фиг.16A сообщения принимают в двух ответах 1604 и 1606. В предшествующей версии клиентского компонента 501 электронной почты, использующего способ быстрой передачи, указание хода выполнения потокового вывода сообщений клиенту не было предусмотрено.

Тем не менее, как показано на Фиг.16B, имеется ответ 1607 на запрос клиентского компонента электронной почты на набор сообщений, при этом серверный компонент 502 электронной почты может предоставить общее количество объектов данных, подлежащих передаче, и общий размер всех объектов данных, подлежащих передаче. Эта информация представлена посредством «P_all» (Р_общ) на Фиг.16B. Серверный компонент 502 электронной почты наиболее недавней версии может также поставлять размер каждого сообщения, указанный посредством «Р₁, Р₂, Р_З, ...» на Фиг.16B. Кроме того, если требуется, то информация, ассоциированная с каждым сообщением и со всей группой сообщений, может включать в себя дополнительную информацию относительно того, является ли каждое сообщение АПИ или действительным сообщением электронной почты. В одном варианте осуществления информацию, представляемую посредством «P_all» на Фиг.16B, всегда посылают в ответ на запрос быстрой передачи, даже если передают нулевые объекты данных, для того, чтобы упростить обработку потока данных.

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

IncrSyncProgressMode
Имя атрибута	Тип атрибута	Примечания
Версия	WORD(например, 16-битовое целое)	Версия данной структуры
cAssocMsgs	DWORD(например, 32-битовое целое)	Количество объектов данных АПИ, подлежащих передаче
llTotalAssocMsgSize	QWORD (например, 64-битовое целое)	Общий размер всех объектов данных АПИ, подлежащих передаче
cNormalMsgs	DWORD	Количество сообщений электронной почты, подлежащих передаче
llTotalNormalMsgSize	QWORD	Общий размер всех сообщений электронной почты, подлежащих передаче

Как может быть видно, отдельные атрибуты могут быть определены для количества объектов данных АПИ, общего размера всех объектов данных АПИ, количества сообщений электронной почты, подлежащих передаче, и общего размера всех сообщений электронной почты, подлежащих передаче. К формату могут быть добавлены другие комбинации и дополнительные атрибуты, как требуется.

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

IncrSyncProgressModePerMsg
Имя атрибута	Тип атрибута	Примечания
Размер сообщения	LONG	Размер следующего сообщения
Флажковый индикатор АПИ	BOOL	Указывает, является ли следующее сообщение АПИ

Как может быть видно, формат включает в себя размер следующего сообщения и то, является или не является следующее сообщение АПИ.

На Фиг.17A и 17B показаны этапы для организации потока набора сообщений в соответствии с предшествующей версией компонентов электронной почты и с наиболее недавней версией компонентов электронной почты соответственно. Этапы согласно Фиг.17A подобны этапам 1501-1503 согласно Фиг.15A. Согласно Фиг.17B, был послан флажковый индикатор PROGRESS_MODE, например, с УОП, клиентским компонентом 501 электронной почты наиболее недавней версии. После того как набор сообщений подготовлен на этапе 1701, осуществляют определение того, есть ли флажковый индикатор. Если есть, то итоговые данные о ходе выполнения посылают на этапе 1702, и затем процесс переходит к этапу 1502, на котором организуют поток первого сообщения. Если флажковый индикатор отсутствует, то от этапа 1701 осуществляют переход непосредственно к этапу 1502.

После того как организован поток первого сообщения, процесс переходит к этапу 1703, на котором определяют, доступен ли флажковый индикатор. Если доступен, то от этапа 1703 осуществляют переход к этапу 1704, на котором для сообщения организуют поток данных о ходе выполнения. Затем процесс приступает к этапу 1503, описанному ранее. Если флажковый индикатор не доступен, то от этапа 1703 осуществляют переход непосредственно к этапу 1503.

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

PtagIncrSyncProgressMode [PT_BINARY]

[содержимое, как описано таблицей)

ptagMessageListStart

ptagIncrSyncProgressModePerMsg [PT_BINARY]

[содержимое, как описано таблицей]

ptagMessageStart

ptagPropList

ptagSubject [PT_STRING]

«Комментарий: Ваша электронная почта»

...

ptagMessageEnd

ptagIncrSyncProgressModePerMsg [PT_BINARY]

[содержимое, как описано таблицей]

ptagMessageStart

...

ptagMessageEnd

PtagIncrSyncProgressModePerMsg [PT_BINARY]

[содержимое, как описано таблицей]

ptagMessageStart

...

ptagMessageEnd

ptagMessageListEnd

В показанном примере метки свойств (ptag), включающие в себя итоговые данные о ходе выполнения (ptagIncrSyncProgressMode), и метки свойств для данных о ходе выполнения сообщения (ptagIncrSyncProgressModePerMsg) размещены перед перечнем сообщений и перед каждым сообщением соответственно. Тем не менее, структура выводимых объектов данных может быть пересмотрена, так что данные о ходе выполнения могут быть включены в состав сообщений или в состав перечня сообщений. Дополнительно возможно пересматривать структуру организации потока объектов данных для того, чтобы устранить метки свойств, ограничивающие сообщения и/или списки сообщения полностью.

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

Существуют несколько различных наборов символов, которые могут быть использованы при хранении сообщений или других объектов данных электронной почты. Например, коды ASCII являются самым обычным применением для хранения символов английского языка. Однако коды ASCII не достаточны для хранения символов для всех языков, поскольку основаны на 8-битовых символах. Таким образом, код ASCII может быть использован только для 256 символов, что является достаточным для английского языка, но недостаточно для языков, которые имеют большее количество символов. С другой стороны, Уникод является набором символов, который использует 16 битов (два байта) для каждого символа и, следовательно, может включать в состав больше символов, чем ASCII. Уникод может иметь 65536 символов и, следовательно, может быть использован для кодирования почти всех языков мира. Уникод включает в себя набор символов ASCII.

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

Для указания, что клиентский компонент 501 электронной почты запрашивает электронную почту, которая должна быть представлена в Уникоде, клиентский компонент 501 электронной почты может, например, выдавать флажковый индикатор, как, например, FORCEUNICODE, к серверному компоненту 502 электронной почты. Флажковый индикатор может быть передан с запросом, таким как УОП. Если серверный компонент 502 электронной почты является наиболее недавней версией, то серверный компонент 502 электронной почты может обеспечить, если доступна, версию Уникода для электронной почты, или может преобразовать сообщения электронной почты, представленные в другом наборе символов, в Уникод.

На Фиг.20 показаны этапы для обеспечения в соответствии с одним аспектом настоящего изобретения конкретного набора символов для сообщения. Начиная с этапа 2001, серверный компонент 502 электронной почты извлекает сообщение из своего хранилища данных. На этапе 2002 осуществляют определение, присутствует ли флажковый индикатор FORCEUNICODE. Если нет, то от этапа 2002 осуществляют переход к этапу 2003, на котором серверный компонент 502 электронной почты передает сообщение электронной почты в обозначенной кодовой странице клиентского компонента электронной почты, преобразуя, если необходимо.

Если флажковый индикатор FORCEUNICODE присутствует, то от этапа 2002 осуществляют переход к этапу 2004, на котором осуществляют определение, сохраняют ли сообщение в представлении Уникод. Если да, то от этапа 2004 осуществляют переход к этапу 2005, на котором сообщение передают клиентскому компоненту 501 электронной почты в наборе символов Уникод. Если сообщение не сохраняют в Уникоде, то от этапа 2004 осуществляют переход к этапу 2006, на котором сообщение преобразуют в Уникод, и затем процесс продолжают на этапе в 2005, на котором сообщение поставляют клиентскому компоненту электронной почты в Уникод.

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

Использование терминов «один», «некоторый» и «конкретный» и аналогичных ссылок в контексте изложения изобретения (особенно в контексте формулы изобретения) должно быть истолковано, как относящееся как к единственному, так и ко множественному числу, если выше не указано иное или четко не указано по контексту. Термины "состоящий из", "имеющий", "включающий в себя" и "содержащий" должны быть истолкованы как открытые термины (т.е. в смысле "включающий в себя, но не ограниченный перечисленным"), если особо не оговорено иное. Описание областей значений в настоящем документе предназначено для того, чтобы служить в качестве способа сокращения (стенографии) при индивидуальной ссылке к каждому отдельному значению, находящемуся в пределах области, если не указано иное, и каждое отдельное значение является включенным в состав описания, как если бы было описано в документе индивидуально. Все способы, описанные выше, могут быть выполнены в любом подходящем порядке, если выше не указано иное или иное четко противоречит по контексту. Использование каких-либо и всех примеров или иллюстративного языка (например, «такой, как»), представленных в настоящем описании, предназначено для лучшего освещения изобретения и не накладывает ограничение на объем изобретения, кроме указанного в формуле изобретения. Язык описания не должен быть истолкован как указывающий какой-либо не заявленный в формуле изобретения элемент в качестве существенного для практической реализации изобретения.

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

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

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

2. Способ по п.1, в котором запрос содержит запрос на синхронизацию папки, в которой сообщение размещено.

3. Способ по п.1, в котором запрос содержит запрос на копию сообщений электронной почты.

4. Способ по п.1, в котором при выборе используют флажковый индикатор, включенный в состав запроса.

5. Способ по п.1, в котором на этапе определения оценивают доступные текстовые блоки сообщения в соответствии с системой ранжирования.

6. Считываемый компьютером носитель, содержащий

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

7. Считываемый компьютером носитель по п.6, в котором запрос содержит запрос на синхронизацию папки, в которой размещено сообщение электронной почты.

8. Считываемый компьютером носитель по п.6, в котором запрос содержит запрос на копию сообщений электронной почты.

9. Считываемый компьютером носитель по п.6, в котором индикация содержит флажковый индикатор, включенный в состав запроса.

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

11. Считываемый компьютером носитель по п.10, в котором запрос содержит запрос на синхронизацию папки, в которой размещены объекты данных электронной почты.

12. Считываемый компьютером носитель по п.10, в котором запрос содержит запрос на копию объектов данных.

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

14. Считываемый компьютером носитель по п.10, в которой по меньшей мере одно свойство содержит заголовок для сообщения.

15. Считываемый компьютером носитель по п.10, в котором объекты данных электронной почты содержат сообщения электронной почты.

16. Считываемый компьютером носитель по п.6, в котором запрос идентифицирует клиентский компонент электронной почты и включает в себя запрос на по меньшей мере одно сообщение электронной почты и индикацию, что клиентский компонент электронной почты требует, чтобы сообщения электронной почты были в формате Уникода.

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

18. Считываемый компьютером носитель по п.16, в котором запрос содержит запрос на синхронизацию папки, в которой размещено сообщение электронной почты.

19. Считываемый компьютером носитель по п.16, в котором запрос содержит запрос на копию сообщений электронной почты.

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

21. Считываемый компьютером носитель по п.20, в котором запрос содержит запрос на синхронизацию папки, в которой размещены объекты данных.

22. Считываемый компьютером носитель по п.20, в котором запрос содержит запрос на копию сообщений электронной почты.

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

24. Считываемый компьютером носитель по п.20, в котором по меньшей мере одно свойство содержит заголовок сообщения.

25. Считываемый компьютером носитель по п.20, который содержит исполняемые компьютером инструкции, в соответствии с которыми

принимают от клиентского компонента электронной почты запрос на по меньшей мере одно сообщение электронной почты и индикацию, что клиентский компонент электронной почты требует, чтобы сообщения электронной почты были в формате Уникода;

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

26. Считываемый компьютером носитель по п.25, в котором индикация содержит флажковый индикатор, включенный в запрос.

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

28. Считываемый компьютером носитель по п.25, в котором запрос содержит запрос на копию сообщений электронной почты.