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

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

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

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

Фиг.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 может перенимать некоторые условные обозначения из предыдущих чертежей