СПОСОБ И СИСТЕМА ДЛЯ СИНХРОНИЗАЦИИ МНОЖЕСТВЕННЫХ ПОЛЬЗОВАТЕЛЬСКИХ РЕВИЗИЙ СОВМЕСТНО ИСПОЛЬЗУЕМОГО ОБЪЕКТА Российский патент 2010 года по МПК G06F17/30 

Уровень техники

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

Раскрытие изобретения

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

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

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

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

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

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

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

Фиг.4 - исходная страница совместно используемого объекта и соответствующая конфликтная страница согласно настоящему изобретению.

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

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

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

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

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

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

Осуществление изобретения

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

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

Иллюстративная рабочая среда

Согласно фиг.1 одна иллюстративная система для реализации изобретения включает в себя вычислительное устройство, например вычислительное устройство 100. Вычислительное устройство 100 может быть сконфигурировано как клиент, сервер, мобильное устройство или любое другое вычислительное устройство, которое взаимодействует с данными в сети на основе системы сотрудничества. В очень обобщенной конфигурации вычислительное устройство 100 обычно включает в себя, по меньшей мере, один процессор 102 и системную память 104. В зависимости от конкретной конфигурации и типа вычислительного устройства системная память 104 может быть энергозависимой (например, ОЗУ), энергонезависимой (например, ПЗУ, флэш-память и т.д.) или некоторой их комбинацией. Системная память 104 обычно включает в себя операционную систему 105, одно или несколько приложений 106 и может включать в себя программные данные 107. В приложениях 106 может быть реализован модуль 108 синхронизации ревизий, подробно описанный ниже.

Вычислительное устройство 100 может иметь дополнительные приспособления или функциональные особенности. Например, вычислительное устройство 100 может также включать в себя дополнительные устройства хранения данных (сменные и/или стационарные), например магнитные диски, оптические диски или ленту. Такое дополнительное хранилище представлено на фиг.1 сменным хранилищем 109 и стационарным хранилищем 110. Компьютерные среды хранения могут включать в себя энергозависимые и энергонезависимые, сменные и стационарные среды, реализованные любым методом или технологией хранения информации, например, компьютерно-считываемых команд, структур данных, программных модулей или других данных. Системная память 104, сменное хранилище 109 и стационарное хранилище 110 являются примерами компьютерных сред хранения. Компьютерные среды хранения включают в себя, но без ограничения, ОЗУ, ПЗУ, ЭСППЗУ, флэш-память или другую технологию памяти, CD-ROM, цифровые универсальные диски (DVD), или другое оптическое хранилище, или другие магнитные запоминающие устройства, или любую другую среду, которую можно использовать для хранения полезной информации и к которой может осуществлять доступ вычислительное устройство 100. Любые такие компьютерные среды хранения могут составлять часть устройства 100. Вычислительное устройство 100 может также иметь устройство(а) 112 ввода, например клавиатуру, мышь, перо, устройство речевого ввода, устройство тактильного ввода и т.д. Также в его состав могут входить устройства 114 вывода, например дисплей, громкоговорители, принтер и т.д.

Вычислительное устройство 100 также содержит средства связи 116, которые позволяют устройству осуществлять связь с другими вычислительными устройствами 118, например, по сети. Сети включают в себя локальные сети и глобальные сети, а также другие крупномасштабные сети, включая, но без ограничения, интранеты и экстранеты. Средство связи 116 является одним примером сред связи. Среды связи обычно реализуются компьютерно-считываемыми командами, структурами данных, программными модулями или другими данными в сигнале, модулированном данными, например несущей волне или другом транспортном механизме, и включают в себя любые среды переноса информации. Термин «сигнал, модулированный данными» означает сигнал, одна или несколько характеристик которого изменяется таким образом, чтобы кодировать информацию в сигнале. В порядке примера, но не ограничения, среда передачи данных включает в себя проводные среды, например проводную сеть или прямое проводное соединение, и беспроводные среды, например акустические, РЧ, инфракрасные и другие беспроводные среды. Используемый здесь термин «компьютерно-считываемые среды» включает в себя среды хранения и среды связи.

Синхронизация множественных пользовательских ревизий совместно используемого файла

На фиг.2 показана блок-схема системы для синхронизации множественных пользовательских ревизий совместно используемого объекта. Объект может быть любой сущностью, которую можно совместно использовать, например файлом. Система включает в себя клиенты 200, 210, 220, 230, почтовый сервер с возможностью хранения файлов, например коммутационный сервер 240, а также веб-сервер 250, одноранговую сеть 260 и вложение 270 электронной почты. Клиенты 210, 220 подключены к веб-серверу 250. Клиенты 210, 220 подключены друг к другу через одноранговую сеть 260. Вложение 270 электронной почты предназначено для переноса веб-сервером 250 к и от клиента 230. Клиенты 210, 220 связаны с одним и тем же пользователем (Пользователем 1). Например, Пользователь 1 осуществляет доступ к клиенту 200 дома, а к клиенту 210 - на работе. Клиенты 220, 230 связаны с разными пользователями (Пользователем 2 и Пользователем 3 соответственно). Каждый из клиентов 200, 210, 220, 230 включает в себя кэш 202, 212, 222, 232 для локального хранения совместно используемого объекта. Одноранговая сеть 260 включает в себя виртуальный сервер 262 для переноса совместно используемого объекта между клиентами 210, 220. Файл 242 ревизии и совместно используемые объекты 252, 264, 272 хранятся в коммутационном сервере 240, веб-сервере 250, виртуальном сервере 262 и вложении 270 электронной почты соответственно. Файл 242 ревизии и совместно используемые объекты 252, 264, 272 могут быть связаны с идентификатором одноранговой группы. Идентификатор одноранговой группы идентифицирует пользователей, уполномоченных осуществлять доступ к конкретному совместно используемому объекту (т.е. одноранговой группе) и ревизовать его. Согласно одному варианту осуществления идентификатор одноранговой группы является унифицированным указателем ресурса (URL) одноранговой группы, который может разрешаться любым веб-клиентом. Совместно используемые объекты 252, 264 связаны с файлами 254, 266 декларации соответственно.

Многие разные пользователи могут одновременно осуществлять доступ к одному и тому же совместно используемому объекту, редактировать и обновлять его с использованием нескольких разных транспортных механизмов. Например, Пользователь 1 на клиенте 210 и Пользователь 2 на клиенте 220 могут осуществлять доступ к совместно используемому объекту 252 из веб-сервера 250. Совместно используемый объект хранится локально в соответствующем кэше 212, 222. Пользователь 1 и Пользователь 2 могут ревизовать совместно используемый объект 252. Ревизии синхронизируются с совместно используемым объектом 252 на веб-сервере 250, так что Пользователь 1 может видеть ревизии, произведенные Пользователем 2, и Пользователь 2 может видеть ревизии, произведенные Пользователем 1.

В другом примере Пользователь 3 может осуществлять доступ к совместно используемому объекту 272 совместно с Пользователем 2 через вложение 270 электронной почты. Пользователь 2 может ревизовать локально хранящийся совместно используемый объект и посылать сообщение электронной почты Пользователю 3, присоединив к нему весь совместно используемый объект или только ревизии совместно используемого объекта. Ревизии, произведенные Пользователем 2, синхронизируются с совместно используемым объектом 252 на веб-сервере 250. Когда электронная почта поступает на клиента 230, ревизии, произведенные Пользователем 2, автоматически синхронизируются с локальным совместно используемым объектом, хранящемся в кэше 232. Пользователь 3 может делать дальнейшие ревизии совместно используемого объекта 272 и отсылать обратно Пользователю 2 весь совместно используемый объект или только ревизии совместно используемого объекта в виде вложения 270 электронной почты. Ревизии, произведенные Пользователем 3, синхронизируются с совместно используемый объектом 252 на веб-сервере 250. Совместно используемый объект на клиенте 220 также обновляется на предмет включения ревизий, произведенных Пользователем 3.

В другом примере Пользователь 1 может осуществлять доступ к совместно используемому объекту либо дома, на клиенте 200, либо на работе, на клиенте 210, через коммутационный сервер 240. Коммутационные серверы часто используются, когда доступ к внешнему серверу не разрешен или отсутствует. Файл 242 ревизии включает в себя ревизии совместно используемого объекта. Файл 242 ревизии можно переносить между клиентами 200, 210 через интерфейс универсальной последовательной шины (USB), приложение электронной почты или какой-либо другой механизм, позволяющий переносить ревизии в любом направлении. Ревизии поступают на клиенты 200, 210, что позволяет обновлять локальный совместно используемый объект, хранящийся в кэшах 202, 212.

Коммутационный сервер 240 может иметь ограничения по размеру файлов, которые он может обрабатывать (например, максимум 2 мегабайта). Пользователь 1 может выгрузить файл 242 ревизии, который включает в себя любые ревизии совместно используемого объекта, с клиента 200 на коммутационный сервер 240. Файл 242 ревизии можно переносить от клиента 200 на клиент 210 подразделами, когда файл 242 ревизии превышает ограничения по размеру, действующие на коммутационном сервере 240. Файловый протокол допускает процесс запроса/выполнения для переноса подразделов. Согласно одному варианту осуществления коммутационный сервер 240 связан с приложением электронной почты. Ревизии, произведенные другим пользователем (Пользователем 2), можно переносить с клиента 220 на клиента 210 через веб-сервер 250 или одноранговую сеть 260, а затем переносить на клиента 200 через учетную запись электронной почты, созданную для Пользователя 1. Согласно другому варианту осуществления клиент 200 периодически опрашивает коммутационный сервер 240 на предмет текущего файла ревизии.

В другом примере между клиентами 210, 220 может быть создана одноранговая сеть 260 в случае потери соединения от клиентов 210, 220 к веб-серверу 250 или когда Пользователь 1 и Пользователь 2 предпочитают осуществлять связь напрямую и синхронно в реальном времени. Пользователь 1 и Пользователь 2 могут предпочитать осуществлять связь через одноранговую сеть 260, потому что совместное использование объекта через веб-сервер 250 может приводить к возникновению разницы по времени, когда ревизии производятся на клиенте 210 и когда ревизии становятся доступны на клиенте 220. Разница по времени может приводить к увеличению нагрузки на сервер. Одноранговая сеть 260 позволяет переносить ревизии совместно используемого объекта напрямую между клиентами 210, 220, а не через веб-сервер 250. Согласно одному варианту осуществления одноранговая сеть 260 является прямой сетью протокола управления передачей/интернет-протокола (TCP/IP). Прямая сеть TCP/IP позволяет быстро сохранять и извлекать ревизии.

Каждый из клиентов 210, 220 может иметь копию совместно используемого объекта 252, хранящуюся в кэше 212, 222, на случай разрыва соединения с веб-сервером 250. Идентификатор одноранговой группы, связанный с совместно используемым объектом 252, указывает, что Пользователь 1 и Пользователь 2 одновременно осуществляют доступ к совместно используемому объекту. Пользователи узнают друг о друге, когда они оба осуществляют доступ к созданной одноранговой сети (например, когда оба пользователя работают на портативных компьютерах в одном и том же самолете). Одноранговая сеть 260 позволяет Пользователю 1 и Пользователю 2 одновременно осуществлять доступ к ревизиям совместно используемого объекта 264 на виртуальном сервере 262 и реализовать дополнительные ревизии. Ревизии мгновенно дублируются на клиентах 210, 220, что позволяет Пользователю 1 и Пользователю 2 активно сотрудничать в отношении совместно используемого объекта 264. Одноранговая сеть 260 может быть заблокирована, когда Пользователь 1 и Пользователь 2 уже не находятся столь близко друг от друга (например, когда пользователи расходятся по своим офисам) или когда Пользователь 1 и Пользователь 2 больше не желают осуществлять связь в реальном времени. Тогда доступ к совместно используемому объекту 252 можно осуществлять через веб-сервер 250. Переход между осуществлением доступа к ревизиям совместно используемого объекта посредством одноранговой сети 260 и посредством веб-сервера 250 осуществляется автоматически и плавно.

Клиенты 210, 220 могут принимать текущие ревизии как от веб-сервера 250, так и из одноранговой сети 260. С каждой ревизией, сделанной в совместно используемом объекте, связывают глобально-уникальный идентификатор (GUID) и метку времени. Метка времени указывает время производства ревизии. Клиент 210 может изменять совместно используемый объект 252 на веб-сервере 250. Клиент 220 определяет, является ли локальная версия совместно используемого объекта в кэше 222 текущей, сравнивая GUID и метку времени, связанные с кэшированным объектом, с GUID и меткой времени, связанными с совместно используемым объектом 252 на веб-сервере 250. Если текущая версия не сохранена локально, то самые последние ревизии, которые не были реализованы в кэшированном объекте, загружаются с веб-сервера 250 на клиент 220 и синхронизируются с локальным файлом. Таким образом, совместно используемый объект не требуется целиком загружать на клиент 220 всякий раз при обновлении локальной версии совместно используемого объекта.

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

Клиент 220 может принять другую ревизию из одноранговой сети 260. Совместно используемый объект в кэше 222 обновляется. Клиент 220 определяет, доступно ли текущее состояние совместно используемого объекта также на веб-сервере 250, используя GUID и метку времени, связанные с ревизией. Если совместно используемый объект 252 на веб-сервере 250 не синхронизирован с текущим состоянием совместно используемого документа, то клиент 220 подает на веб-сервер 250 самую последнюю ревизию, что позволяет обновить совместно используемый объект 252.

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

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

Файл декларации может храниться в любом месте системы. Как показано на фигуре, файл 254 декларации связан с совместно используемым объектом 252. Совместно используемый объект 252 и файл 254 декларации хранятся на веб-сервере 250. Согласно другому варианту осуществления файл декларации хранится в совместно используемом объекте. Согласно еще одному варианту осуществления файл декларации хранится в активной директории. Согласно еще одному варианту осуществления файл декларации хранится во многих местах в системе. Файл декларации хранится в месте, указанном уникальным идентификатором положения. Уникальный идентификатор положения может указывать файловый сервер, совместно используемую область сервера, веб-сервер или одноранговую группу.

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

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

Согласно другому варианту осуществления клиент 210 может осуществлять доступ к совместно используемому объекту 264 из одноранговой сети 260. Клиент 210 извлекает файл 266 декларации, связанный с совместно используемы объектом 264. Клиент 210 может подключиться к серверу и определить, какие клиенты также подключены к серверу. В отсутствие одноранговой сети 260 доступ к подключенным клиентам можно осуществлять через сервер. Совместно используемый объект 264 (или 252) и связанный с ним файл 264 (или 254) декларации позволяют клиенту 210 (или клиенту 220) автоматически и плавно переходить между асинхронным и синхронным режимами связи.

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

На фиг.3 показан иерархический граф из связанных узлов, обозначающих различные части совместно используемого объекта. Согласно одному варианту осуществления совместно используемый объект представляет собой блокнот, совместно используемый несколькими пользователями. Узел 300 блокнота обозначает весь совместно используемый объект. Узел 310 папки включен в узел 300 блокнота. Узел 320 раздела включен в узел 310 папки. Узлы 330, 335 страницы включены в узел 310 раздела. Узел 340 таблицы, узел 342 рукописного ввода, узел 344 схемы и узел 346 изображения включены в узел 330 страницы. Узел 350 элемента схемы включен в узел 344 схемы. Узел 360 текста включен в узел 350 элемента схемы. Различные узлы могут быть сгруппированы в контейнер контента. Например, узел 344 схемы, узел 350 элемента схемы и узел 360 текста могут быть сгруппированы в контейнер контента R0. Контейнеру контента R0 присвоен GUID (например, GUID-0). GUID уникально идентифицирует контейнер контента R0.

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

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

Например, два разных пользователя могут осуществлять доступ к совместно используемому документу и изменять контейнер контента R0. Один пользователь может ревизовать контейнер контента R0, удалив узел 360 текста (что показано в ревизии R1). Ревизия R1 сохраняется в совместно используемом объекте. Ревизии R1 присваиваются GUID (например, GUID-1), чтобы уникально идентифицировать ревизованный контейнер, и метка времени, которая идентифицирует время и дату, когда ревизия R1 записана в совместно используемый объект. Другой пользователь может ревизовать контейнер контента R0, добавив узел 380 текста к узлу 350 элемента схемы (что показано в ревизии R2). Ревизия R2 сохраняется в совместно используемом объекте. Ревизии R2 присваивается метка времени и GUID (например, GUID-2), чтобы уникально идентифицировать ревизованный контейнер контента.

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

Например, пользователь может ревизовать контейнер контента совместно используемого объекта, который идентифицирован как ревизия R1 путем добавления узла 370 элемента схемы к узлу 344 схемы (что показано как ревизия R3). Ревизия R3 сохраняется в совместно используемом объекте. Ревизии R3 также присваивается метка времени и GUID (например, GUID-3), чтобы уникально идентифицировать ревизованный контейнер контента. Ревизия R3 является продолжением ревизии R1. Таким образом, ревизия R1 является самой поздней версией совместно используемого объекта, о которой знает пользователь (например, локально сохраненной версией). Совместно используемый объект проверяют, чтобы определить, по-прежнему ли самой поздней версией совместно используемого объекта является ревизия R1. Согласно одному варианту осуществления самую позднюю версию совместно используемого объекта можно определить, сравнив метки времени и GUID разных контейнеров контента. Если самая поздняя версия совместно используемого объекта связана с более новой меткой времени, чем ревизия R1, значит, другой пользователь (например, пользователь, создавший ревизию R2) позднее изменил тот же самый контейнер контента.

Если другой пользователь изменил тот же самый контейнер контента после того, как ревизия R1 была синхронизирована с совместно используемым объектом, то никакие ревизии, являющиеся продолжением ревизии R1 (например, ревизия R3), не могут быть синхронизированы с совместно используемым объектом, пока все последующие ревизии не будут синхронизированы с совместно используемым объектом и пока не будут разрешены и объединены все конфликтующие ревизии. Например, ревизия R2 синхронизируется с совместно используемым объектом после ревизии R1. Таким образом, самая поздняя версия совместно используемого объекта включает в себя ревизию R2. Прежде чем синхронизировать ревизию R3 с совместно используемым объектом, ревизию R3 сравнивают с ревизией R2, чтобы определить, имеется ли конфликт ревизий. Сравнение необходимо, поскольку ревизия R3 является продолжением ревизии R1, которая уже не связана с самой поздней версией совместно используемого объекта. Определяют, что ревизия R3 не конфликтует с ревизией R2, поскольку узел 370 элемента схемы можно добавить к узлу 344 схемы, не нарушая ревизию R2.

Согласно одному варианту осуществления совместно используемый объект ревизуют, перемещая контейнер контента из одного места в другое в совместно используемом объекте. Например, узел 340 таблицы можно переместить из узла 330 страницы в узел 335 страницы. Производят определение, что узел 340 таблицы перемещен в новое место, но не могут определить, в какое. В исходном положении узла 340 таблицы создают узел посредника. Узел посредника реализуют в новом положении узла 340 таблицы, когда определено новое положение узла 340 таблицы. Если узел таблицы 340 удаляют до того, как определено новое положение, то узел посредника отбрасывают.

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

Например, ревизия R4 является продолжением ревизии R3. Ревизия R4 удаляет узел 350 элемента схемы из узла 344 схемы. Определено, что самая поздняя версия совместно используемого объекта включает в себя ревизию R2. Сравнение между ревизией R2 и ревизией R4 выявляет конфликт, поскольку узел 350 элемента схемы присутствует в ревизии R2, но удален в ревизии R4.

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

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

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

На фиг.4 показана исходная страница совместно используемого объекта и связанная с ней конфликтная страница. Исходная страница 400 включает в себя неконфликтующие ревизии, например контейнеры 410, 420 контента. Любые согласованные конфликтующие ревизии указаны на исходной странице 400 индикатором конфликта. Согласно одному варианту осуществления индикатор конфликта является выпадающим меню 430. Первый элемент выпадающего меню 430 может быть самыми последними конфликтами, созданными пользователем. Элемент выпадающего меню 430 может включать в себя имя пользователя и соответствующую метку времени. Другой элемент выпадающего меню 430 может включать в себя другие конфликтные страницы, которые пользователь создал, но не согласовал. Другие элементы выпадающего меню 430 могут соответствовать конфликтным страницам, созданным другими пользователями. При выборе элемента выпадающего меню 430 отображается соответствующая конфликтная страница с конфликтующими ревизиями, выделенными для привлечения внимания пользователя к ревизиям, которые не были объединены в исходную версию совместно используемого объекта. Таким образом, пользователь может либо согласовать конфликты с исходной страницей 400, либо решить, что конфликты малозначительны.

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

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

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

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

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

На фиг.5 показана блок-схема системы для синхронизации множественных пользовательских ревизий совместно используемого объекта. Система включает в себя клиенты 500, 510, 540, 550 и серверы 520, 530. Клиент 500 связан с серверами 520, 530. Клиент 510 связан с сервер 520. Клиенты 540, 550 связаны с сервером 530. Клиент 540 включает в себя хранилище 542 и дочернее хранилище 544. Сервер 520 включает в себя хранилище 522 и дочерние хранилища 524, 526. Сервер 530 включает в себя хранилище 532. Хранилище 532 включает в себя подхранилища 534, 536.

В хранилищах 522, 532, дочерних хранилищах 524, 526 и подхранилищах 534, 536 могут храниться ревизии, связанные с совместно используемым объектом. Хранилище 522, 532, дочерние хранилища 524, 526 и подхранилища 534, 536 являются иерархическими. Например, хранилище 522 может быть связано со всем совместно используемым документом блокнота. Дочернее хранилище 524 может быть связано с разделом совместно используемого документа блокнота. Дочернее хранилище 526 может быть связано со страницей совместно используемого документа блокнота. Согласно одному варианту осуществления в хранилище 522 включается только самая последняя версия совместно используемого объекта верхнего уровня. В хранилище 532 может храниться весь совместно используемый объект верхнего уровня. Подхранилища 534, 536 связаны с частями совместно используемого объекта. Например, подхранилище 534 может быть связано с разделом совместно используемого объекта, и подхранилище 536 может быть связано с другим разделом совместно используемого объекта.

Приложение может загружать совместно используемый объект с сервера 520 или сервера 530 на клиент 500 без текущей версии конкретного контейнера контента совместно используемого объекта. Например, клиент 500 запрашивает совместно используемый объект из хранилища 522. Клиенту 500 предоставляется самая последняя доступная версия совместно используемого объекта. Самая последняя доступная версия совместно используемого объекта может не соответствовать текущей версии совместно используемого объекта, поскольку данные самой последней версии отсутствуют в соответствующем дочернем хранилище 526. Дочернему хранилищу 526 присваивают тег запроса, указывающий, что клиент 500 запрашивает самые последние данные ревизии для обновления совместно используемого объекта. Дочернему хранилищу 526 можно также присвоить метку времени, указывающую время и дату, когда клиент 500 запросил данные ревизии из дочернего хранилища 526. Дочернему хранилищу можно также присвоить GUID, который идентифицирует клиент, запросивший данные (например, клиент 500). Тег запроса, метка времени и GUID используются для информирования клиента 500, когда другой клиент осуществляет доступ к дочернему хранилищу 526. Например, клиент 510 может обращаться к дочернему хранилищу 526, содержащему самые свежие данные ревизии. Таким образом, клиент 500 узнает, что самые свежие данные ревизии совместно используемого объекта доступны в дочернем хранилище 526.

Клиент 500 может представлять собой домашний компьютер пользователя, а клиент 540 может представлять собой рабочий компьютер пользователя. Сервер 530 может представлять собой коммутационный сервер, переносящий файл ревизии между клиентами 500, 540. Файл ревизии можно использовать для обновления совместно используемого объекта, хранящегося на клиентах 500, 550. Согласно одному варианту осуществления клиент 500 не может обрабатывать файлы, большие заранее определенного размера (например, 2 мегабайта). Например, клиент 500 может включать в себя приложение электронной почты, которое ограничивает размер принимаемых сообщений электронной почты. Хранилище 542 включает в себя ревизии, связанные с совместно используемым объектом верхнего уровня. Дочернее хранилище 544 включает в себя ревизии, связанные с контейнером контента совместно используемого объекта.

Клиент 540 может опрашивать сервер 530, чтобы определить, подал ли другой клиент запрос на ревизию данных. Клиент 540 может удовлетворить запрос, когда самая поздняя версия запрошенной ревизии данных доступна в хранилище 542 или дочернем хранилище 544. Клиент 540 может перевести всю запрашиваемую ревизию на клиент 500, если размер файла ревизии меньше предельного размера, который может обработать клиент 500. Если размер файла ревизии больше этого предельного размера, то файл можно разделить на более мелкие файлы, размеры которых меньше этого предельного размера. Альтернативно, размер файла ревизии можно уменьшить, удалив предыдущие запросы. Затем более мелкие файлы переносятся с клиента 540 на клиента 500 через сервер 530.

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

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

На фиг.6 показана логическая блок-схема процесса синхронизации множественных пользовательских ревизий совместно используемого объекта. Процесс начинается с начального блока, на котором многие пользователи одновременно получают полномочия на доступ к совместно используемому объекту и его ревизию (т.е. образуют одноранговую группу). Объектом может быть любая сущность, которую можно совместно использовать, например файл. Одноранговую группу можно идентифицировать идентификатором одноранговой группы. Разные версии совместно используемого объекта идентифицируются соответствующими GUID и метками времени. Метка времени указывает время, когда совместно используемый объект был последний раз синхронизирован с ревизией.

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

На блоке 620 выявляют самую позднюю версию совместно используемого объекта. Самая поздняя версия совместно используемого объекта - это версия, которая включает в себя самые последние ревизии, синхронизированные с совместно используемым объектом и ставшие доступными другим уполномоченным пользователям. Самую позднюю версию совместно используемого объекта можно определить из меток времени и GUID, связанных с разными версиями совместно используемого объекта.

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

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

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

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

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

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

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

На фиг.8 показана логическая блок-схема процесса синхронизации множественных пользовательских ревизий совместно используемого объекта. Процесс начинается с начального блока, на котором разные версии совместно используемого объекта хранятся в разных местах системы. На блоке 800 совместно используемый объект загружается из хранилища на клиент.

На блоке 810 производится определение, является ли совместно используемый объект текущей версией совместно используемого объекта. Если совместно используемый объект является текущей версией совместно используемого объекта, то обработка заканчивается на конечном блоке. Если совместно используемый объект не является текущей версией совместно используемого объекта, то обработка переходит к блоку 820. Совместно используемый объект может не являться текущей версией, поскольку в хранилище отсутствует самая последняя ревизия контейнера контента совместно используемого объекта.

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

На блоке 830 текущая версия совместно используемого объекта поступает в хранилище. Хранилище может принимать текущую версию совместно используемого объекта, когда другой клиент обращается к хранилищу с самыми последними данными ревизии. Запрашивающего клиента информируют о том, что текущая версия совместно используемого объекта поступила в хранилище. На блоке 840 текущая версия совместно используемого объекта синхронизируется с запрашивающим клиентом. Затем обработка заканчивается на конечном блоке.

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

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

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

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

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

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

На блоке 1010 файл декларации, связанный с совместно используемым объектом, извлекается из места, указанного уникальным идентификатором положения. Файл декларации указывает места в системе, где хранятся другие версии и экземпляры совместно используемого объекта. На блоке 1020 клиент подключается к серверу. Клиент определяет, какие другие клиенты также подключены к серверу. На блоке 1030 клиент идентифицирует другие клиенты, которые уполномочены осуществлять доступ к совместно используемому объекту из одноранговой сети. На блоке 1040 клиент подключается к уполномоченному клиенту, когда одноранговая сеть недоступна. Затем процесс заканчивается на конечном блоке.

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

Изобретение относится к системе связи и предназначено для синхронизации множественных пользовательских ревизий совместно используемого объекта. Технический результат - повышение точности синхронизации. Множество разных пользователей могут одновременно осуществлять доступ к одному и тому же совместно используемому объекту, ревизовать и обновлять его через несколько разных транспортных механизмов. Ревизии совместно используемого объекта автоматически синхронизируются, что позволяет всем пользователям просматривать ревизии совместно используемого объекта. Конфликтующие ревизии согласуются и объединяются в текущую версию совместно используемого объекта. Клиент может запрашивать текущую версию совместно используемого объекта из хранилища, когда текущая версия совместно используемого объекта недоступна из хранилища. Текущая версия совместно используемого объекта синхронизируется с клиентом, когда хранилище принимает текущую версию совместно используемого объекта. 3 н. и 7 з.п. ф-лы, 10 ил.

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

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

3. Компьютерно-реализуемый способ по п.1, в котором при приеме запроса клиента дополнительно присваивают хранилищу тег запроса и информацию клиента.

4. Компьютерно-реализуемый способ по п.1, в котором при приеме наиболее поздней версии совместно используемого объекта дополнительно принимают наиболее позднюю версию совместно используемого объекта, когда другой клиент осуществляет доступ к хранилищу с наиболее поздней версией совместно используемого объекта.

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

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

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

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

9. Система по п.8, в которой средство приема запроса клиента дополнительно содержит средство присвоения хранилищу тега запроса и информации клиента.

10. Система по п.8, в которой средство приема наиболее поздней версии совместно используемого объекта дополнительно содержит средство приема наиболее поздней версии совместно используемого объекта, когда другой клиент осуществляет доступ к хранилищу с наиболее поздней версией совместно используемого объекта.