RU2507567C2 - Многопользовательское сетевое сотрудничество - Google Patents

Abstract

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

Description

Уровень техники изобретения

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

Сущность изобретения

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

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

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

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

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

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

Фиг.3 - логическая блок-схема процессов для инициирования совместных усилий (например, редактирования) для конкретного документа.

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

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

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

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ

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

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

На фиг.1 показаны системы или операционные среды, обозначенные, в целом, как 100, для обеспечения многопользовательского сетевого сотрудничества. Эти системы 100 могут включать в себя одну или несколько серверных систем 102, причем реализации этого описания включают в себя любое количество внешних и/или внутренних серверов, как описано более подробно ниже. Серверы могут включать в себя один или несколько процессоров 104, которые могут иметь конкретный тип или конкретную архитектуру, выбранный/ую надлежащим образом для конкретной реализации. Процессоры 104 могут подключаться одной или нескольким шинным системам 106, выбранным для совместимости с процессорами 104.

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

Носители данных 108 могут включать в себя один или несколько модулей инструкций, которые, при загрузке в процессор 104 и выполнении, предписывают серверу 102 осуществлять различные техники для облегчения многопользовательского сетевого сотрудничества. В частности, носители данных 108 могут включать в себя модули инструкций, которые обеспечивают коллективные клиентские службы 110 для множества клиентских систем. На фиг.1 показано два примера таких клиентских систем, как 112a и 112n (в целом, клиентские системы 112). Однако реализации этого описания могут включать в себя ряд клиентских систем.

Носители данных 108 могут содержать один или несколько экземпляров хранилища 114 документов. Хотя дополнительные детали, касающиеся хранилища документов, приведены ниже, в целом, хранилище документов вмещает или содержит документы, которые множество клиентских систем может совместно редактировать или создавать. Хотя на фиг.1 показан сценарий, в котором хранилище 114 документов и программное обеспечение для коллективных клиентских служб 110 располагаются на одних и тех же носителях данных 108, этот пример приведен только для простоты иллюстрации, но не для ограничения возможных реализаций. Особо заметим, что в некоторых сценариях хранилище документов и коллективные клиентские службы могут располагаться на разных носителях и/или в отдельных системах или физических устройствах.

Более подробно рассматривая коллективные клиентские службы 110, можно видеть, что эти службы могут облегчать потоки сотрудничества между серверами 102 и клиентскими системами 112. На фиг.1 показано два примера потоков сотрудничества, причем потоки сотрудничества 116a представляют данные и потоки обработки между сервером 102 и клиентской системой 112a, и потоки сотрудничества 116 представляют данные и потоки обработки между сервером 102 и клиентской системой 112n.

Более подробно рассматривая клиентские системы 112, можно видеть, что эти клиентские системы могут включать в себя соответствующие процессоры 118a и 118n (в целом, процессоры 118), которые могут иметь или не иметь такой же тип и архитектуру, что и процессор 104. Шинные системы 120a и 120n (в целом, системы 120) могут подключаться соответственно к процессорам 118a и 118n, как показано на фиг.1. Эти шинные системы 120 могут быть совместимы по типу и архитектуре с соответствующими процессорами 118 и могут иметь или не иметь такой же тип и архитектуру, как шинные системы 106 на сервере 102. Соответствующие экземпляры компьютерно-считываемых носителей данных 122a и 122n (в целом, носителей данных 122) могут содержать программное обеспечение браузера 124a и 124n (в целом, браузеры 124).

Клиентские системы 112 и серверные системы 102 могут кооперировать, как описано здесь, чтобы соответствующие конечные пользователи 126a и 126n (в целом, конечные пользователи 126) могли сотрудничать в редактировании и/или создании документов (целиком или частично) из хранилища 114 документов. В некоторых сценариях, разные конечные пользователи 126 могут совместно редактировать один и тот же фрагмент данного документа. В других сценариях, разные конечные пользователи 126 могут работать над разными фрагментами данного документа.

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

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

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

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

На фиг.2 показаны компоненты и потоки данных, обозначенные, в целом, как 200, относящиеся к инициированию процессов сотрудничества, показанных на фиг.1. Для простоты описания, но не ограничения, фиг.2 может перенимать некоторые условные обозначения из предыдущих чертежей для обозначения сходных элементов. Например, фиг.2 перенимает из фиг.1 представление коллективных клиентских служб 110, хранилища документов 114, сети 128, браузеров 124 и пользователей 126.

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

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

Коллективные клиентские службы 110 могут передавать одну или несколько ревизий из данного конкретного документа для сотрудничества разных конечных пользователей 126 через браузеры 124. Например, коллективные клиентские службы 110 могут определять, какие ревизии в данном документе представляют интерес для разных конечных пользователей, и затем могут передавать эти ревизии для отображения в браузерах для этих конечных пользователей. На фиг.2 обозначены как 206a примеры ревизий, передаваемых в браузер 124a для взаимодействия с пользователем 126a, обозначены как 206b примеры ревизий, передаваемых в браузер 124b для взаимодействия с пользователем 126b, и обозначены как 206n примеры ревизий, передаваемых в браузер 124n для взаимодействия с пользователем 126n.

Коллективные клиентские службы 110 могут определять, какие конкретные ревизии 206 данного документа подлежат распределению на различные клиентские браузеры. Например, коллективные клиентские службы могут сначала передавать на браузеры навигационную страницу, содержащую имена всех страниц в данном документе, совместно с контентом только первой страницы. На браузерах, разные пользователи могут затем кликать по своим соответствующим навигационным страницам и выбирать, какие страницы они хотели бы видеть и редактировать. Коллективные клиентские службы затем могут загружать содержимое выбранных страниц в различные браузеры. Например, разные пользователи 126 могут прокручивать одни и те же или разные страницы в данном документе. В этом примере, когда коллективные клиентские службы определяют страницы, которые разные пользователи хотят редактировать, клиентские службы могут получать из хранилища документов 114 те ревизии 208, которые соответствуют этим страницам. В свою очередь, коллективные клиентские службы могут распределять эти ревизии, обозначенные как 206a, 206b и 206n (в целом, распределенные ревизии 206), по соответствующим пользователям.

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

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

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

После того как коллективные клиентские службы распределили конкретные ревизии 206 на браузеры, эти службы могут сохранять информацию сотрудничества, обозначенную, в целом, как 210. Например, эта информация сотрудничества может указывать, какие конкретные ревизии были распределены каким конкретным пользователям. Коллективные клиентские службы могут сохранять эту информацию в хранилище 212 ревизий на стороне сервера, которое может содержать представления 214a и 214m разных пользователей 126 (в целом, пользовательские представления 214). В свою очередь, пользовательские представления 214 могут указывать, какие ревизии, обозначенные 216a и 216m (в целом, ревизионные представления 216), были распределены конкретным пользователям. Как описано более подробно ниже, эти позиции в хранилище ревизий на стороне сервера могут позволять коллективным клиентским службам определять, какие ревизии, сделанные конкретными пользователями, могут относиться к другим пользователям.

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

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

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

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

Блок 306, в целом, представляет передачу полученных ревизий, представляющих интерес, конкретным пользователям. Например, предполагая, что три разных пользователя сотрудничают по поводу данного документа, как показано на фиг.2 (например, пользователи 126a, 126b и 126n), эти пользователи могут проявлять интерес к одним и тем же или разным фрагментам этого данного документа. Соответственно, блок 306 может включать в себя передачу ревизионных представлений соответствующих фрагментов данного документа этим разным пользователям (например, 206a, 206b и 206n).

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

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

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

На фиг.4 показаны компоненты и потоки, обозначенные, в целом, как 400, которые могут иметь место на стороне браузера для инициирования сотрудничества на данной клиентской системе. Для простоты описания, но не ограничения, фиг.4 может перенимать некоторые условные обозначения из предыдущих чертежей для обозначения сходных элементов. Например, фиг.4 перенимает из предыдущих чертежей сеть 128, распределенные ячейки 206, браузер 124 и пользователя 126.

Рассматривая более подробно фиг.4, можно видеть, что менеджер дублирования 402 клиентской стороны может принимать распределенные ревизии 206 от сервера 102 по сети 128. Эти ревизии 206 могут представлять страницы, первоначально представленные пользователю 126, или могут представлять ревизии, сделанные в отношении этих ячеек другими сотрудничающими пользователями. В целях описания фиг.4, предполагается, что ячейки 206 представляют страницы, первоначально представленные пользователю 126, посредством браузера 124.

В общем случае, менеджер дублирования 402 может осуществлять обмен ревизиями ячеек между браузером и сервером. Менеджер дублирования также может надлежащим образом трансформировать протоколы между сетью и браузером. Согласно фиг.4, предполагается, что ревизии, обозначенные как 206, соответствуют протоколу, пригодному для сетевой передачи, тогда как ревизии, обозначенные как 404, трансформируются в соответствии с требования обработки браузером.

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

Хранилище 406 ревизий может обеспечивать представление ячеек в виде структуры данных графа 410, который обеспечивает семантическую модель совместно редактируемого документа, причем эта семантическая модель обеспечивает иерархию документа. Предполагая реализацию модели данных/просмотра, структура графа 410 может обеспечивать фрагмент данных этой модели. Структура графа 410 может представлять собой ориентированный ациклический граф, включающий в себя вершины разных типов, наборы свойств и другие элементы, представляющие входящие ячейки 206. На фиг.4 приведены примеры вершин, обозначенных как 412a и 412n (в целом, вершины 412 графа). Например, предполагая, что входящая ревизия представляет страницу совместно редактируемого документа, разные вершины 412 в структуре графа 410 могут представлять разные абзацы, изображения, страницы, разделы или другие фрагменты или подэлементы в странице. Некоторые объекты можно представлять одной вершиной в графе (например, изображение), тогда как другой контент, например таблицы, можно представлять многими вершинами в графе.

В иллюстративных, но не ограничительных реализациях, менеджер дублирования 402 клиентской стороны, хранилище 406 ревизий на стороне клиента, начальное состояние 408 ячейки и структуру графа 410 можно прописывать на Script# и реализовывать в JavaScript. Однако эти примеры приведены только для облегчения этого описания, и в других реализациях возможны другие сценарии.

Структура графа 410 может обеспечивать независимую от браузера модель контента, представленного входящими ревизиями 206. В свою очередь, вершины 412 в этой структуре графа можно визуализировать в любом из различных частично доступных браузеров. Соответственно, модель просмотра или код просмотра 414 может визуализировать или отображать эти вершины 412 из структуры графа 410 в модель просмотра, зависящую от браузера. На фиг.4 приведен пример такой модели просмотра в виде объектной модели документа (DOM) 416. В DOM 416 может храниться текущий вид совместно редактируемого документа, представляющий фотографии, изображения, списки или другие элементы, присутствующие на одной или нескольких страницах документа.

Код просмотра 414 может создавать DOM из структуры графа 410, причем вершины 412a и 412n в структуре графа соответствуют вершинам 418a и 418n (в целом, вершинам 418 DOM) в DOM. Затем DOM 416 можно визуализировать на браузере 124 для просмотра пользователем 126. На фиг.4 показано, что этот фрагмент визуализируемого контента пользователь может наблюдать в любое данное время как окно просмотра 420 браузера. Затем пользователь может взаимодействовать, по своему усмотрению, с любыми элементами, представленными в окне просмотра браузера.

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

На фиг.5 показаны компоненты и потоки, обозначенные, в целом, как 500, для обработки ревизий, сделанных в отношении документов сотрудничающими пользователями. Для простоты описания, но не ограничения, фиг.5 может перенимать некоторые условные обозначения из предыдущих чертежей для обозначения сходных элементов. Например, фиг.5 перенимает из предыдущих чертежей сеть 128, браузеры 124, пользователей 126, коллективные клиентские службы 110, хранилище ревизий 212 на стороне сервера и соответствующие представления пользователей 214 и ревизий 216.

Рассматривая более подробно фиг.5, предположим, что пользователи 126a и 126b сотрудничают по поводу одной и той же ячейки в данном документе. Эта ячейка, обозначенная на фиг.5 как 502a и 502b, обобществлена между пользователями 126a и 126b. Как описано выше, хранилище 212 ревизий на стороне сервера может создавать и сохранять пользовательские представления 214 и ревизионные представления 216 для указания этого сценария. Если пользователь 126a создает ревизии 504a в отношении обобществленной ячейки 502a, браузер 124a может передавать эти ревизии коллективным клиентским службам 110. Извещение о ревизиях 504a также может указывать ревизованную ячейку 502a.

Получив извещение о ревизиях 504a, коллективные клиентские службы 110 могут определять, относятся ли эти ревизии 504a к ячейкам, редактируемым другими пользователями. Для производства такого определения коллективные клиентские службы 110 могут запрашивать хранилище 212 ревизий на стороне сервера, чтобы определить, редактируют ли ячейку 502a какие-либо другие пользователи. В этом случае, этот запрос будет указывать, что пользователь 126b также редактирует ячейку 502a, которая только что была ревизована. Кроме того, браузер 124b может запрашивать коллективные клиентские службы 110 на предмет новых изменений в ячейке 502. Таким образом, сервер, на котором выполняются коллективные клиентские службы, может неявно определять, что два клиента сотрудничают в отношении ячейки 502. Соответственно, в некоторых сценариях, коллективные клиентские службы 110 могут формировать и посылать извещение об этих ревизиях на браузер 124b. В других сценариях, коллективные клиентские службы могут принимать запросы от браузера 124b и могут отвечать на такие запросы соответствующими ревизиями для ячейки 502. На фиг.5 эти и другие сценарии, в целом, представлены как 504b. В свою очередь, браузер 124b может обновлять свое отображение для включения ревизий 504b.

В этом сценарии, показанном на фиг.5, предполагается, что пользователь 126n редактирует ячейку 506, которая отличается от ячейки 502a и 502b (в целом, ячейки 502), обобществленной пользователями 126a и 126b. Хотя эти разные ячейки 502 и 506 могут быть в одном и том же документе, пользователь 126n в данный момент не редактирует ячейку 502. В этом сценарии, ревизии этой ячейки, 502 сделанные другими пользователями, не имеют непосредственного отношения к пользователю 126n и/или браузеру 124n. Поэтому коллективные клиентские службы 110 не извещают сразу же браузер 124n об этих ревизиях, тем самым экономя полосу сети, связанную с таким извещением. Однако пользователь 126n может делать ревизии 508 в отношении ячейки 506, причем эти ревизии передаются на коллективные клиентские службы 110 надлежащим образом. В свою очередь, коллективные клиентские службы могут передавать эти ревизии на любые другие браузеры или другим пользователям, которые редактируют ту же ячейку 506.

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

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

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

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

Рассматривая более подробно фиг.6, блок 602 представляет прием указателей ревизий, сообщенных одним или несколькими браузерами (например, 124 в предыдущих чертежах). Например, блок 602 может включать в себя прием коллективными клиентскими службами 110 указателей таких ревизий, которые обозначены на фиг.5 как 504a и 508.

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

Блок 606, в целом, представляет сохранение сообщенных ревизий, принятых на блоке 606. Например, блок 606 может включать в себя сохранение этих ревизий в хранилище ревизий на стороне сервера (например, 212).

Блок 608 принятия решения представляет определение, делают ли какие-либо другие браузеры запрос на просмотр и/или редактирование данной ячейки, которая была ревизована. Если никакие другие браузеры в данный момент не запрашивают данную ячейку в данное время, то потоки обработки 600 может принимать решение «Нет» 610 для возврата к блоку 602 и ожидания извещения о следующей ревизии ячейки от одного из браузеров.

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

После осуществления блока 614, потоки обработки 600 могут возвращаться к блоку 602 в ожидании следующего извещения о ревизиях от браузеров. Описав потоки для обработки ревизий, сообщенных различными сотрудничающими браузерами на фиг.6, перейдем к описанию компонентов и потоков данных, имеющих место на стороне браузера, для обработки этих ревизий. Это описание приведено со ссылкой на фиг.7.

На фиг.7 показаны компоненты и потоки данных, обозначенные, в целом, как 700, которые браузер может обеспечивать для обработки ревизий в отношении контента, который совместно редактируется множеством пользователей. Для простоты описания, но не ограничения, фиг.7 может перенимать некоторые условные обозначения из предыдущих чертежей для обозначения сходных элементов. Например, фиг.7 перенимает из предыдущих чертежей сеть 128, иллюстративного пользователя 126, иллюстративный браузер 124, иллюстративную DOM 416, иллюстративный код просмотра или модель просмотра 408 и иллюстративную структуру графа 410. Фиг.7 также перенимает хранилище 406 ревизий на стороне клиента, которое может включать в себя начальное состояние 408 ячеек, отображаемое в браузере 124 для редактирования пользователем 126. Кроме того, фиг.7 перенимает менеджер дублирования 402, который может сообщать ревизии 504 от браузера по сети 128.

Рассматривая более подробно фиг.7, можно видеть, что пользователь 126 может подавать различные команды для взаимодействия с контентом, представленным в браузере 124, и может делать любое количество ревизий в отношении этого контента посредством этих команд. Эти команды 702 могут быть различных типов, в зависимости от типа контента, представленного в браузере, и в зависимости от того, какие возможности делаются доступными браузеру через коллективные клиентские службы (например, 110 в предыдущих чертежах).

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

Вершины в структуре графа могут обновляться в соответствии с командами 702, причем обновляются только те вершины, которые подвергаются действию команд. После обновления вершин, подвергнутых воздействию, код просмотра 408 может обходить эти вершины и наполнять DOM, например, соответствующим HTML-кодом. В свою очередь, браузер 124 может обходить DOM и визуализировать HTML для отображения пользователю 126. Таким образом, браузер 124 может позволять пользователю 126 визуализировать результаты любых команд, вводимых пользователем.

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

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

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

Хотя в хранилище 406 ревизий могут храниться дельты, представляющие большинство или все ревизии, осуществляемые на локальном браузере, хранилище 406 ревизий может сообщать или не сообщать все эти ревизии серверу по сети 128. Например, при наличии полного множества дельт 704 ревизии, осуществляемых локально на браузере, хранилище 406 ревизий может сообщать некоторое подмножество этих дельт ревизии (обозначаемое как 706) менеджеру дублирования 402. В свою очередь, менеджер дублирования может переправлять эти ревизии, обозначенные как 504, на сервер. В частности, менеджер дублирования в браузере может определять, когда переправлять эти ревизии на сервер, чтобы не создавать неоправданных помех пользовательским взаимодействиям, происходящим в браузере. В конце концов, менеджер дублирования на данном браузере может переносить на сервер объединенные или накопленные результирующие изменения, сделанные пользователем на этом браузере. Менеджер дублирования на браузере может объединять ревизии и дельты ревизии, происходящие на браузере, для задания результирующей ревизии, которая имитирует объединенные или накопленные изменения ячейки, тем самым устанавливая текущее состояние ячейки. В свою очередь, менеджер дублирования может передавать текущее состояние ячейки на сервер.

Описав компоненты и потоки данных на стороне браузера для обработки ревизий на фиг.7, перейдем к описанию компонентов и потоков данных серверной стороны для обработки этих ревизий. Это описание приведено со ссылкой на фиг.8.

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

В примерах, показанных на фиг.8, иллюстративные пользователи 126a и 126n могут взаимодействовать с иллюстративными браузерами 124a и 124n для создания ревизий 504a и 504n в отношении конкретных ячеек 802a и 802n. В свою очередь, браузеры 124a и 124n могут сообщать эти ревизии коллективным клиентским службам 110 по сети 128.

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

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

Поскольку извещения 504 ревизий поступают от различных браузеров, эти извещения могут указывать, какие ячейки, обозначенные соответственно как 802a и 802n, подвергаются ревизии. Когда коллективные клиентские службы 110 принимают эти извещения, эти службы могут создавать и сохранять дельты 808 ревизии на стороне сервера. С функциональной точки зрения, эти дельты 808 ревизии на стороне сервера могут действовать аналогично дельтам ревизии, описанным на стороне браузера. Однако заметим, что дельты ревизии на стороне сервера могут быть или не быть в точности такими же, как дельты ревизии на стороне браузера.

Описав компоненты и потоки данных серверной стороны для приема и обработки ревизий от браузеров на фиг.8, перейдем к подробному описанию компонентов серверной стороны. Это описание приведено со ссылкой на фиг.9.

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

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

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

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

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

Уровень слияния 914 и связанный с ним движок слияния 916 создает эти интерфейсы и соответствующие способы, которые позволяют уровню хранения задействовать возможности слияния. Например, когда разные браузеры передают на коллективные клиентские службы ревизии в отношении данного контента, уровень хранения может сохранять соответствующие ревизии и/или дельты ревизии в кэшах 910 и 912. По мере необходимости, уровень хранения 906 может вызывать уровень слияния 914 для слияния или согласования этих различных ревизий для обновления контента, в отношении которого сотрудничают браузеры. Кроме того, уровень слияния 914 может определять, когда вызывать и выполнять движок слияния 916, на основании таких факторов, как насколько нагружены или заняты серверы, обеспечивающие коллективные клиентские службы, в любое данное время.

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

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

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

Оптимизация полезной нагрузки данных

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

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

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

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

Выполнение команд в надлежащей среде

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

Кроме того, команды, выполняющиеся на сервере, могут делать это, не создавая помех “нормальной” работе сервера. Например, когда уровень хранения 906 принимает новое изменение, он может передавать его в хранилище 212 ревизий на стороне сервера для хранения. Уровень хранения также может извещать уровень слияния 914 об этом новом изменении. Однако, асинхронно с этим извещением, уровень слияния может пытаться объединить этот новый контент, когда это необходимо. Эта асинхронная операция может минимизировать опасность перегрузки сервера, чтобы он не был слишком занят для обработки других запросов. Таким образом, уровень слияния может действовать только, если внешний сервер имеет достаточно свободных циклов, чтобы заниматься слиянием.

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

Хранение на сервере

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

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

Многопользовательское редактирование

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

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

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

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

Claims (16)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Images