Содержание
2017. Google Docs порадовал любителей совместных правок
Вообще-то онлайн редактор Google Docs изначально делал упор на совместное редактирование документов в режиме реального времени. Но иногда бывает, что нужно совместно поработать над документом в асинхронном режиме. И вот тогда в игру вступают исправления, принятие/отклонение, версии документа. Теперь этот режим редактирования (обычный для Word) доступен и в Google Docs. Причем, правки можно вносить/принимать и в мобильном приложении. И в отличии от Word, в Google Docs лучше видно, кто вносил изменения. Также появилась возможность именовать версии документов, что очень удобно. Например, после утверждения первой части документа, можно назвать версию «1 часть утверждена» вместо «Версия от 3 августа».
2017. Приложение Dropbox Paper доступно на русском языке
Dropbox объявил о глобальном запуске своего приложения Paper на 21 языках, в т.ч. на русском. Это инструмент для совместной работы — нечто среднее между Evernote, Google Docs и Slack. Вы создаете страничку, приглашаете коллег (зарегистрированных в Dropbox) и можете совместно создавать и редактировать контент. При этом, видно кто что редактирует в данный момент. На страничку можно добавлять картинки, файлы, видео, списки задач и комментарии. Работать со страничкой можно в браузере или мобильном приложении. По окончании работы страничка сохраняется в вашем аккаунте Dropbox. На данный момент приложение Paper — бесплатно.
2015. Dropbox запустил сервис для онлайн заметок и совместной работы
Dropbox тихо запустил новый сервис Dropbox Notes. Он представляет собой простой текстовый редактор, с помощью которого вы можете создать заметку (или простой документ) и сохранить ее в своем онлайн хранилище. Текст можно немного форматировать, добавлять картинки и таблицы. К заметкам можно прикреплять файлы и задачи (to-do листы). Кроме того, странички можно расшаривать для коллег и совместно редактировать их в реальном времени. При этом вы видите, кто сейчас еще редактирует страничку и где находится его курсор. Конечно, этот редактор не будет конкурировать с Word, он предназначен для простой организации совместной работы. Тем более, что недавно Dropbox получил полноценную интеграцию с Microsoft Office.
2015. Dropbox позволяет совместно редактировать документы MS Office
Несколько лет назад, когда все уже думали, что будущее документов — в том, что они будут храниться только в онлайне, появился Dropbox и придумал синхронизировать копию документа между многими устройствами. Теперь, когда все уже смирились с тем, что для совместного редактирования документа нужен онлайн редактор типа Google Docs, Dropbox предлагает не паниковать и пользоваться привычными Word, Excel и PowerPoint, просто установив небольшой плагин для совместной работы. Этот плагин Dropbox badge позволяет в реальном времени синхронизировать копии одного и того-же документа на компьютерах сотрудников. При этом, вы можете видеть, кто в данный момент работает над данным документом, определить, последняя ли у вас версия, обновиться до самой свежей версии и быстро отправить коллеге ссылку на документ. Новая фича будет доступна сначала в бизнес-версии Dropbox for Business.
2012. Salesforce Stypi — онлайн блокнот для совместной работы в реальном времени
Допустим, вам с коллегами или партнерами нужно поработать над какой-то задачей, требующей писанины. Например, составить план проекта или написать коммерческое предложение клиенту. Если все участники совещания присутствуют в офисе, вы их просто собираете за одним столом, берете бумажку или флипчарт и записываете умные мысли. Но если участники совещания находятся в разных уголках планеты? Конечно есть Google Docs, Online Word или Zoho, но в них нужно всем регистрироваться, и они очень громоздкие для написания простых списков. (Иногда какие-то мелочи отталкивают людей от использования сервиса). Так вот, для таких онлайн совещаний отлично подойдет сервис Stypi. Это простой онлайн блокнот с чатом, в котором могут работать несколько человек одновременно.
2011. Google+ Hangouts превратился в полноценный сервис web-конференций
Хак ливанского программиста, который позволял совместно редактировать текст в Google+ Hangouts недолго оставался хаком. Сегодняшнее обновление Google+ добавило в сервис Hangouts гораздо больше новых возможностей. Во-первых, это возможность расшаривать свой экран (Screen-sharing). Во-вторых, это возможность совместно рисовать на экране (Whiteboard). В-третьих, это возможность совместно редактировать документы Google Docs. В-четвертых, это возможность устраивать видеотрансляции (вебинары) на неограниченное количество зрителей (число активных участников может быть до 10). В-пятых, видеочат Google Hangouts работает теперь и на Android-смартфонах. И наконец, в-шестых, Google открыл официальный API для Hangouts, так что теперь не нужно извращаться, как ливанский программист, чтобы создать собственное приложение для Hangouts. Кстати, социальная сеть Google+ теперь открыта для всех. Ваша компания уже подготовилась к этому?
2011. Совместное редактирование текста/кода в Google+ Hangouts
Некий разработчик Мохамед Мансур создал расширение к Google+ Hangouts — Hangout Pad for Google+, которое позволяет совместно работать над текстом (или программным кодом), общаясь по видеосвязи. Хотя это расширение пока содержит кучу багов, оно интересно сразу по нескольким причинам. Во-первых, оно не использует официальный Google+ API (по той простой причине, что его еще не существует). Hangout Pad представляет собой плагин к браузеру Google Chrome и встраивается в видеочат Hangouts посредством хака (сервиса Google Shared Spaces и протокола Google Wave). Тем не менее, этот инструмент уже сейчас показывает возможности расширения Google Hangouts (берегись Skype!). Окно для совместной работы (в данном случае редактор кода) расположено над видеопотоками пользователей и в нем может быть все что угодно. Кроме того, это наглядная демонстрация будущей интеграции Google Hangouts с Google Docs.
2011. В TeamLab появился текстовый редактор и электронные таблицы
Сервис для совместной работы Teamlab продолжает удивлять. Хотя недавно в нем наконец-то появилась платная версия, основной функционал остается абсолютно бесплатным и не ограниченным по количеству пользователей. И при этом у разработчиков есть время, деньги и желание на создание таких новых фич, как онлайн редакторы документов. Да, они решили не интегрировать уже готовые редакторы Google Docs или Zoho Docs, а создать свои собственные (конкурирующие) приложения. Текстовый редактор и редактор электронных таблиц уже доступны, в т.ч. в бесплатной версии. Скоро появится и редактор презентаций. Конечно, функционал этих приложений пока далек от Word, Excel и даже от Google Docs, в них есть только базовые функции. Но для большинства ежедневных операций по совместной работе с документами — они вполне подойдут. Созданные в Teamlab документы можно скачать в форматах DOC, XLS и отправить контрагентам. Можно также загружать документы в этих форматах и редактировать их в онлайне.
2011. TeamLab добавил модуль для совместной работы с документами
Сервис для совместной работы и управления проектами Teamlab получил новый модуль — Documents, который предназначен для хранения и совместного доступа к файлам и документам. Документы можно легко импортировать из Google Docs, Zoho Docs и Box.net, а для их редактирования можно использовать OpenOffice + специальный плагин Teamlab, которые позволяют открыть любой документ прямо из браузера. У каждого пользователя есть персональное хранилище документов и расшаренная папка, в которой происходит совместная работа. Кроме модуля документов в Teamlab появились шаблоны проектов (для быстрого создания типовых проектов), история переписки, мультичат и групповая рассылка в мессенджере TeamLab Talk, страница Мои задачи, сроки задач и кнопка-напоминание.
2010. OffiSync добавил почти-real-time совместное редактирование в MS Office и Google Docs
OffiSync — это плагин для редакторов MS Office, который позволяет сохранять офисные документы в аккаунте Google Docs, а затем их оттуда открывать. Т.е. идея сервиса — объединение функциональных редакторов MS Office с возможностями совместной работы Google Docs. C момента нашего последнего обзора, создатели прикрутили интеграцию с Google Sites (т.е. документ из MS Office можно сохранять как аттачмент к выбранной страничке в Google Sites и открывать документы оттуда). А вчера появилась еще более интересная фича — возможность одновременно редактировать один документ, работая в любой версии MS Office (2003, 2007, 2010) или в онлайн редакторе Google Docs. Конечно, это выглядит не так, круто, как в новой (вчерашней) версии Google Docs, зато объединяет пользователей обоих решений.
2010. Zoho Business позволяет ограничить доступ к приложениям по IP
Конечно, возможность доступа к бизнес-приложениям из любого места в мире — это стратегическое преимущество Zoho и других SaaS сервисов. Но с точки зрения безопасности, это может привести к большим проблемам. В Zoho решили устранить этот недостаток и для пользователей Zoho Business вводят возможность ограничить доступ к аккаунту по IP адресу. В контрольной панели появилась закладка, в которой можно ввести список разрешенных IP адресов — обычно это адреса офисов или домашние адреса сотрудников/фрилансеров. Т.к. приложения из Zoho Business часто предполагают доступ внешних контрагентов (клиентов, партнеров), то можно для них не запрещать доступ полностью, а лишь ограничить их права доступа. Напомним, Zoho Business — это пакет офисных приложений для работы с электронной почтой, документами и создания внутреннего портала для совместной работы.
2010. Box.net обновил мобильную версию для iPhone
Box.net был одним из первых сервисов, который создал клиент для iPhone. И теперь он продолжает совершенствовать свой мобильный клиент. Мобильный Box.net 2.0 добавил просмотрщик файлов (который недавно появился в web-версии), возможность комментировать файлы и папки, расшаривать файлы и папки и просматривать общую ленту событий. Кроме того, новый мобильный клиент интегрировали с редакторами документов Quickoffice для iPhone, так что документы а формате Word и Excel можно будет открывать и редактировать на iPhone. В свете недавнего появления iPad эта возможность выглядит особенно привлекательно.
2010. Box.net достойно ответил Google Docs
Наверное, создатели Box.net были не очень рады узнать, что сервис Google Docs превратился в онлайн файлохранилище, а значит, стал их прямым конкурентом. Но их ответный ход не заставил себя долго ждать. На днях Box.net представил универсальный Flash-просмотрщик файлов, напоминающий Scribd, который позволяет просмотреть практически любой файл, хранящийся в Box.net аккаунте — прямо в онлайне, не загружая его на компьютер. Это может быть офисный документ, картинка, флэш, аудио или видео (всего 20 форматов). Кроме того, вы можете опубликовать любой файл (в flash-просмотрщике) на своем сайте или предоставить к нему доступ определенным сотрудникам и контрагентам, чтобы они могли с ним ознакомиться и оставить свои комментарии. Пожалуй, это идеальное решение, когда вы хотите отправить клиенту презентацию, схему, техническую документацию или макет дизайна. Вам не нужно заботиться о том, чтоб у клиента было установлено определенное ПО для того, чтоб открыть файл.
2009. Google купил EtherPad и вспомнил об имидже SaaS
Итак, онлайн сервис совместного редактирования документов в режиме реального времени EtherPad, созданный бывшими сотрудниками Гугла, возвращается туда, где он был рожден — в Google. Цель этой покупки — использовать некоторые технологии EtherPad для Google Wave и привлечь талантливых сотрудников обратно в компанию для работы над проектом, который должен изменить мир. Вчера, как только сделка была оформлена, создатели EtherPad (очевидно, по просьбе новых владельцев) отписали в своем блоге, что с этого момента создавать новые документы на сервисе нельзя, а 31 марта EtherPad будет закрыт. Разумеется, пользователи сервиса были несколько разочарованы таким положением вещей и высказали все что об этом думают в коментах. И тут в Гугле вспомнили об одной штуке, которая для них намного важнее, чем новое приобретение — доверие к SaaS.
2009. EtherPad имитирует функцию PlayBack из Google Wave
30 сентября Google начнет раздачу 100000 приглашений в Google Wave. С момента презентации этого суперсервиса прошло всего 3 месяца, но за это время сторонние разработчики уже успели воплотить в жизнь некоторые его оригинальные идеи. Недавно мы говорили о Zenbe, который реализовал идею «волны», а сегодня сервис для совместного редактирования документов, EtherPad представил фичу «PlayBack», которая является одним из самых замечательных изобретений в Google Wave. Смысл ее в том, что в любой момент можно проиграть всю историю изменения документа, подобно как вы смотрите фильм.
2009. OffiSync: Google Docs и MS Office — не конкуренты
У большинства пользователей, наверно, сложился стереотип, что Google Docs и MS Office — принципиальные конкуренты. Продвинутые пользователи онлайн сервисов постоянно спорят со сторонниками Microsoft о том, что ценнее, многофункциональный и мощный редактор, или возможность глобального доступа и совместной работы в онлайне. Свежим взглядом на этот вопрос посмотрели ребята из OffiSync. Они подумали, ведь все равно почти у всех есть MS Office, и любой юзер может без проблем создать себе аккаунт в Google Docs. Почему бы не использовать эти офисные пакеты вместе, объединяя их преимущества?
2009. DocVerse — оперативная совместная работа в MS Office
Два бывших сотрудника Microsoft создали вспомогательный вэб-сервис (+ плагин) DocVerse, предназначенный для совместной работы над документами MS Office через интернет. Зачем они это сделали? Быть может им нечем занять себя? Ведь у Microsoft уже есть (бесплатный) сервис, предлагающий подобную функциональность — Office Live Workspace. А кроме того, Microsoft уже показала онлайн версии своих редакторов и объявила, что следующий Office 14 будет web-ориентированным. И вряд-ли эти ребята надеятся, что Microsoft купит их проект, иначе бы не строили его на вражеской платформе Adobe AIR.
2008. EtherPad — текстовый редактор для совместной работы в Real Time
Преимущества онлайн редакторов типа Google Docs или Zoho Writer над десктопным Вордом до сих пор сомнительна. В первую очередь из-за их неспособности (пока) обеспечить полную совместимость с форматом .doc (что очень важно для обмена файлами с контрагентами). На этом фоне очень умным кажется стартап EtherPad, создатели которого решили забить на совместимость и форматирование и сосредоточиться на том факторе, который делает онлайн-редактор намного более ценным, чем Word — совместная работа в режиме реального времени.
2008. Gobby — сделаем вместе
Что такое Gobby? Gobby — свободный совместный (коллаборативный) редактор, поддерживающий множество открытых документов для одной сессии и многопользовательский чат. Он может работать в Windows, Mac OSX, Linux. Редактор позволяет нескольким пользователям одновременно редактировать один и тот же документ.
2007. Новые возможности служб Google доступны уже сегодня
IMAP для Gmail, документы Google для мобильных устройств, новые функции для электронных таблиц, новые возможности в Профессиональном пакете и в Пакете для учебных заведений и многое другое в официальном релизе.
2007. Google запустит wiki-приложение: Google Wiki
В Сети появилась информация о том, что Google готовится перезапустить сервис Jotspot, который был куплен компанией в 2006 г. Jotspot является приложением, которое предназначено для работы с онлайновыми wiki-сервисами — базами данных наподобие Wikipedia.После сделки с Google сервис Jotspot не позволял регистрироваться новым пользователям, однако старые клиенты сохранили доступ к своим аккаунтам. Как сообщает Google Blogoscoped, сервис Jotspot войдет в набор онлайновых приложений для офиса Google Apps под названием Google Wiki.О новом названии говорит также и логотип Google Wiki, который появляется при попытке войти на сайт.Представители Google не давали официальных комментариев по поводу этой информации.
2007. Central Desktop интегрировал электронные таблицы
Только недавно мы написали о сильном конкуренте Google Spreadsheets — EditGrid. А сегодня (видимо прочитав этот пост) Central Desktop объявил об интеграции этого сервиса в свою офисную платформу. Так что теперь пользователи Central Desktop получили возможности:
2006. Коллективный редактор зарабатывает на вики-технологиях
Американская компания Numanila разработала сервис Approver, призванный облегчить работу над одним документом нескольких пользователей. Для начала работы нужно загрузить документ на сайт и выбрать из списка своих контактов тех людей, которые будут над ним работать. Таким образом, вместо организации почтовой рассылки с прикрепленным к нему документом и дальнейшей переписки по электронной почте, можно просмотреть на одной странице всю нужную информацию. Сервис покажет, кто и когда вносил в документ правки, кто уже утвердил его, а также напомнит всем участникам работы о сроках «дедлайна».В тестовом режиме пользователь может создать только один документ и принимать участие в работе над неограниченным количеством чужих документов. Для того, чтобы получить возможность создания большего количества документов (до 50-ти), необходимо купить платный аккаунт за $6 в месяц или 40$ в год. При этом сервис работает только на ОС Mac и Windows, и только с браузерами Internet Explorer и Firefox.
2006. Writeboard — работаем вместе
Коллективное создание текстовых документов не является чем-то из ряда вон выходящим: многим из нас это приходилось делать не раз в условиях офисной работы. Но что делать, если соавторы находятся вне интранет сети и даже более того — живут в другой стране или вообще на другом континенте? Обмен рабочими материалами посредством электронной почты рано или поздно приведёт к такой путанице, что можно легко потерять несколько важных дополнений, сделанных коллегами. Конечно, можно найти массу способов избежать проблем и организовать коллективную работу через интернет, но все они будут связаны с определёнными затратами времени и сил. Поэтому предлагаем познакомиться с проектом под названием Writeboard, позволяющим легко и непринуждённо готовить несложные текстовые документы с участием неограниченного числа соавторов.Для начала работы достаточно пройти несложную регистрацию, после чего можно сразу переходить к собственно работе над документом. Средства форматирования предоставляются довольно аскетичные: пара типов заголовков, два вида списков, жирный и наклонный шрифт, вставка текстового блока. Доступно также добавление в документ гиперссылок и изображений. Правда, не без неудобств: картинки предварительно нужно выложить в интернет, т.к. в текст помещается только ссылка на изображение. Редактировать местоположение и размер графических объектов невозможно, поэтому лучше заранее подготовить рабочие материалы, чтобы в дальнейшем готовый вариант статьи выглядел более эстетично. Правка документа не составляет труда, кириллические тексты выглядят вполне прилично как во время редактирования, так и в готовом документе (впрочем, это заслуга, скорее, браузера, чем собственно Writeboard, т.к. выбор шрифтов в программе отсутствует):Готовый документ сохраняется на сервере разработчиков и становится доступным для редактирования другим пользователям. Для отслеживания внесённых изменений предусмотрена система, аналогичная той, что используется в системах Wiki, поэтому находить правки, сделанные другими участниками проекта, можно очень легко. Также остаются доступными и промежуточные версии рабочего документа, благодаря чему всегда можно вернуться к любой из предыдущих версий. Особо следует отметить способ выделения изменённого текста: это позволяет сразу обнаруживать свежие правки, а не искать их по тексту всего документа.Для обсуждения текущих рабочих моментов вы можете обмениваться с коллегами текстовыми сообщениями, организованными в виде комментариев. Выделение промежуточных версий документа, которые являются своего рода отправными точками для начала следующего этапа редактирования, или просто оказались удачными, но не совсем готовыми к финальному релизу версиями, можно осуществлять с помощью установки соответствующих флагов. Если кто-то соавторов ещё не в курсе о том, что над документом уже вовсю кипит работа, в которой его помощь очень даже приветствуется, можно переслать ему приглашение по электронной почте. В сообщении будет содержаться ссылка на текущую версию документа, а также необходимый для доступа к функции редактирования пароль.Помимо вышеперечисленных действий над документом, можно переслать рабочие материалы любому адресату по электронной почте. Для того, чтобы не заниматься рассылками постянно, можно использовать RSS. Если же понадобится копия документа на локальном компьютере, её можно скачать с сервера разработчиков Writeboard, при этом документ автоматически конвертируется в один из двух форматов: простой текст или HTML. Невозможность помещения графических объектов непосредственно в текст создаваемого документа на данном этапе окажет своё негативное влияние: если в тексте присутствовали изображения, то экспортированный вариант будет содержать лишь ссылки на них.Каких-либо особых средств шифрования документов разработчиками Writeboard не предусмотрено, поэтому осуществлять с помощью подобного инструмента внутренний документооборот компании, конечно, не стоит. Но найдётся немало проектов, которым данный сервис окажется как нельзя кстати. Авторы ресурса предлагают воспользоваться своим детищем таким категориям пользователей, как студенты и поэты, свободные журналисты и PR-менеджеры. В любом случае, раз подобный проект предлагает свои услуги — почему бы не попробовать им воспользоваться?
2002. Протокол WebDAV для управления файлами в Web
Компания Software AG выпустила WebDAV — набор расширений протокола HTTP, обеспечивающего функции совместного редактирования и управления файлами на удаленных Web-серверах. Протокол WebDAV дает офисным работникам возможность мгновенно размещать в Web информацию при помощи обычных офисных программ. Сервер Tamino WebDAV Server интегрирует XML-базу данных Tamino в Windows-приложения
Добрый день. Последний год я занимаюсь в проекте «МойОфис» вопросами совместного редактирования (collaboration). Оглядываясь назад, могу констатировать, что это непростая и очень интересная задача. Поэтому я хотел бы подробно рассказать о ней и дать ответы на следующие вопросы:
- Какие существуют подходы к обеспечению совместного редактирования?
- Насколько они сложны в реализации?
- Можно ли взять готовую библиотеку и использовать ее в своем проекте?
- Можно ли вести разработку без оглядки на совместное редактирование?
Для того чтобы подробно и аргументированно ответить на них, необходимо написать довольно много материала, поэтому статей будет несколько, присаживайтесь поудобнее, мы начинаем.
Как только мы начинаем хранить файлы на сервере (в облаке), возникает естественное желание обеспечить их редактирование несколькими людьми. Особенно это актуально для офисных документов, над которыми работают сразу несколько человек и каждый из них вносит правки.
Но «нельзя просто так взять и…» предоставить всем доступ для правки одного документа. Необходим механизм, который обеспечит удобное и корректное изменение одного файла несколькими пользователями. Давайте рассмотрим варианты, как это можно сделать.
Возможные подходы
Блокировка всего документа при редактировании
Это самый тривиальный метод. Преимуществами такого решения являются простота реализации и возможность работы со всеми типами данных. На этом преимущества заканчиваются и начинаются сплошные неудобства для пользователя:
- В один момент времени только один пользователь может вносить правки. Чем больше будет такой документ и чем чаще его будут редактировать, тем более явным становится это неудобство. Представьте себе ТЗ на сотню с лишним страниц, при этом один пользователь вынужден ждать, пока его коллега закончит править раздел в другой части документа.
- Каждое изменение в документе приводит к необходимости полностью передать его на сервер, а затем скачать всем участникам, что сильно ухудшает скорость работы и увеличивает объем пересылаемых данных.
- Данное решение не может обеспечить офлайн-работу, ведь чтобы приступить к редактированию документа, требуется заблокировать его на сервере от изменения другими пользователями. А без соединения с сервером сделать это нельзя.
- Неснятая блокировка. Представим, что один пользователь забыл снять блокировку, да еще и ушел домой или вовсе уехал в отпуск. Всем остальным приходится ждать или искать нерадивого пользователя. Частично от этого можно уйти, контролируя время активности или предоставив администратору возможность принудительно снять блокировку. Впрочем, ни то ни другое не является идеальным решением, так как в первом случае нельзя понять, на основе чего можно отличить пропавший интернет от недисциплинированности пользователя, а во втором нельзя обойтись без вмешательства человека и чьи-то изменения могут быть потеряны.
Такой вариант можно часто встретить в решениях для корпоративных порталов, ERP, СЭД.
Блокировка части документа
Для текстового документа такой единицей деления может стать абзац или таблица. Это улучшает весь процесс работы, а именно:
- Теперь можно одновременно редактировать один документ, при условии, что правки вносятся в разные его части.
- Заблокировать документ полностью нельзя. Несмотря на неснятую блокировку, с остальным документом можно продолжать работать.
Но и этот подход нельзя назвать идеальным:
- По-прежнему нельзя обеспечить офлайн-работу. Для блокировки любой из частей документа необходимо связаться с сервером.
- Часть документа, заблокированная при редактировании, может быть значительной. Действительно, абзац может быть довольно большим и содержать несколько сотен или тысяч знаков текста. Еще больше сложностей возникает при работе с таблицами. Без дополнительных ухищрений нельзя одновременно разрешить менять содержимое ячеек и структуру таблицы — вставлять и удалять строки или столбцы. Это означает, что при любом изменении одной из ячеек требуется блокировать всю таблицу. В офисных документах таблицы могут быть разного уровня вложенности или же очень большого размера. Особенно неприятным этот момент становится при работе с табличными документами, где рабочий лист и вовсе состоит из одной таблицы, а значит при любых изменениях надо его блокировать полностью.
- С точки зрения структуры, документ можно упрощенно представить как последовательность абзацев и таблиц. И когда мы вставляем или удаляем таблицы и абзацы, то мы редактируем эту последовательность. А это значит, что корректность совместного редактирования такой последовательности также необходимо обеспечить (кстати, принципиальной разницы между редактированием списка абзацев или списка букв нет, разве что первое происходит реже). Без введения принципиально другого метода синхронизации это должна быть опять же блокировка, только на этот раз объект блокировки будет один на весь документ.
Некоторые читатели могут заметить, что задача совместного редактирования успешно решается в системах контроля версий, с последовательной историей (SVN или CVS) или с возможностью ветвлений (GIT, Mercurial). Да, вы правы, но и здесь есть свои нюансы, которые делают невозможным применить в нашем случае тот же принцип:
- Merge. Во-первых, для пользователей офисных пакетов это понятие как правило незнакомо. Во-вторых, объединение разных версий документа становится принципиально более трудным при переходе от простого текста к документу со сложной (как правило иерархической) структурой, где есть текст, вложенные таблицы, изображения и различные настройки форматирования. Просто представьте себе подобный 3-way merge.
- Даже при использовании kdiff3 или winmerge случаются ошибки, а ведь они работают с простым текстом.
- Обычному пользователю офисных приложений будет непросто вникнуть в мир ветвлений и слияний. А вникнув, использовать будет не очень быстро и удобно.
Взгляд с другой стороны
Будем исходить из того, что с точки зрения пользователя вся работа с документом должна сводиться лишь к тому, чтобы исправить текст, вставить график, обещанный коллегам, и на этом закончить. Так же, как он это делал раньше с локальными документами. Все сложные процессы по поддержке корректного состояния документа должны быть скрыты от пользователя. При этом важно сохранить отзывчивость и функциональность, сравнимую с редактированием локальных файлов.
Для нас это диктует дополнительные требования:
1. Использование оптимистичной стратегии внесения изменений. К локальной копии документа правки должны применяться сразу. И независимо от этого они отправляются на сервер, а от него к другим клиентам, при этом то, как быстро они будут получены и применены, никак не влияет на скорость работы с локальной версией.
Отсюда следует, что состояния документа у клиентов и на сервере могут отличаться. Это формирует следующее требование:
2. Сходимость (convergence). Когда все пользователи закончат свою работу и все уведомления о правках будут доставлены, как на сервере, так и у клиентов должно быть одно и то же состояние документа.
Но это еще не все. Первые два требования можно выполнить с помощью простого, но явно не устраивающего пользователей алгоритма. Если на сервер приходят два конкурирующих изменения, то можно просто игнорировать то, что пришло позже, уведомив соответствующим образом клиентов. Этого будет достаточно, чтобы удовлетворить первые два требования, но явно недостаточно, чтобы сделать счастливым того, чьи изменения были выкинуты. А это значит, что нужно задекларировать еще одно требование:
3. Принцип сохранения намерений (intention preservation). Мы должны обеспечить максимальное сохранение намерений всех пользователей, даже если правки вносятся одновременно и они конкурируют друг с другом.
Мы декларируем, что каждая правка от каждого из пользователей важна для нас и мы не будем отменять ее без необходимости. Необходимость отменить все же может возникнуть. Например, в таких ситуациях, когда один пользователь отредактировал абзац, который параллельно был удален кем-то другим. В этом случае изменения уже просто нельзя применить, так как абзац более не существует.
Второй момент, который стоит упомянуть в контексте этого принципа, — формализация. Понятие «намерение» достаточно абстрактно. Представим, что в тексте есть слово «оптека», которое параллельно исправляют два пользователя, причем по-разному: «аптека» и «оптика». Большинство известных алгоритмов (и наш тоже) работают на уровне букв, и в результате получится «аптика», что не соответствует «высокоуровневым» намерениям обоих авторов. Существуют формализации намерений пользователей на уровне слабых порядков букв («хочу вставить букву «и” после буквы «т”, но перед «к”»). Для некоторых алгоритмов сохранение выраженных таким образом намерений является неотъемлемой их частью (об этом можно почитать ).
В нашем случае мы не формализуем намерения пользователей и тем более не даем строгих гарантий их соблюдения, но декларируем, что будем максимально придерживаться этого принципа.
Выбор неблокирующего алгоритма
Существуют два алгоритма, которые удовлетворяют всем нашим требованиям: оптимистичное внесение изменений, сходимость и сохранение намерений.
Первый. Differential synchronization. Который в итоге нам не подошел
Алгоритм предполагает постоянный 3-way merge на стороне клиента и сервера, который сопровождается пересылкой патчей в обе стороны. На схеме представлена общая идея.
Более подробное описание можно увидеть на сайте автора.
Вероятно, вы уже догадались, по какой причине этот алгоритм нам не подходит. Правильно, как уже упоминалось, 3-way merge для документа со сложной структурой нетривиален. При этом необходимо иметь формальную гарантию того, что он даст одинаковые результаты при слияниях в разных порядках и направлениях… Это ставит крест на перспективе применения у нас данного подхода.
Второй. Operation Transformation (OT)
Это скорее общий подход, на основе которого разработаны различные алгоритмы.
В основе OT лежит довольно простая идея. Все изменения данных мы описываем как операции, которые пересылаем и преобразуем относительно других без самого документа. Когда операция приходит от одного пользователя к другому, мы ее трансформируем таким образом, чтобы она стала валидной относительно разницы между документами этих двух пользователей, выраженной в операциях. Звучит заумно, но на самом деле принцип довольно простой.
Что такое Operation Transformation
Давайте посмотрим на еще одну схему, которая популярна в статьях об OT.
Операция О2:
- Пользователю 1 приходит операция О2 del от пользователя 2.
- Операция О2 трансформируется относительно операции О1, которой не было у пользователя 2 на момент создания О2.
- В результате получается del, так как перед позицией 2 уже успели вставить один символ и у «с” позиция стала 3.
Операция О1:
- Пользователю 2 от пользователя 1 приходит операция О1 ins.
- O1 трансформируется относительно О2, но на этот раз при трансформации операция не меняется и применяется в таком же виде, как и у автора операции — пользователя 1.
Здесь используется трансформация включения (в некоторых алгоритмах используется и трансформация исключения). В дальнейшем я буду использовать обозначение Inc(O1, O2) для операции О1 с учетом эффектов операции О2, то есть, если кратко, мы включили О2 в О1.
Основное требование, которому должны удовлетворять трансформации включения (известное как Transition Property 1), — это:
Inc(O2, O1) * O1 = Inc(O1, O2) * O2,
где * — последовательное применение, справа налево. Для простоты понимания посмотрите на изображение:
Приведенное выше равенство в применении к этой картинке означает, что, начав с одного состояния документа и двигаясь по правой или левой ветке, мы получим одно и то же итоговое состояние. Принципиальным моментом является то, что начинать «движение» мы должны из одного и того же состояния. Если это условие не соблюдать, то результатом будет рассогласованное состояние документов либо трансформированная операция может просто не иметь смысла. Например, вставка символа в неверную или несуществующую позицию документа.
Как я указал выше, существует несколько различных алгоритмов на основе ОТ. Их главным отличием является решение ключевого вопроса: как производить трансформации таким образом, чтобы любые операции, участвующие в трансформации, были над одним и тем же состоянием документа, и, если такой возможности нет, то с помощью каких еще преобразований можно изменить порядок применения операций.
Дело в том, что первые алгоритмы на основе ОТ не предусматривали использования центрального сервера. Все клиенты связывались между собой peer-to-peer. Соответственно, текущее состояние документа у пользователей выражалось последовательностью операций (О1, О2… ОN), при этом в каждый момент времени количество, состав и порядок этих операций у каждого клиента может быть свой. В этом случае нельзя определить единый строгий порядок среди всех генерируемых операций, можно ввести только слабый порядок по happens before критерию. Операции, между которыми нет такого отношения, считаются конкурирующими или параллельными (concurrent).
Подобный подход также несет с собой определенные сложности:
- Производительность. Количество трансформаций может быть очень большим, клиентам приходится хранить всю историю, так как в любой момент может прийти сколь угодно «древняя» операция от другого пользователя.
- Для корректной реализации требования TP-1 уже недостаточно. Приходится требовать еще и как минимум TP-2: Inc(O3, Inc(O1, O2) * O2) = Inc(O3, Inc(O2, O1) * O1). В зависимости от конкретного алгоритма может понадобиться выполнение других требований к трансформациям и обратным операциям (полный список ). Если у вас есть набор операций, то эти требования должны быть выполнены для любой пары или тройки, а это далеко не всегда так. При этом, чтобы иметь уверенность в сходимости алгоритма, эти требования необходимо формально верифицировать, то есть доказать, как теорему.
- Сложность. Подобные алгоритмы действительно непростые, и порой в них находят ошибки. Например, один из случаев, потенциально приводящий к ошибке, выглядит вот так:
Интересующиеся классическими peer-to-peer алгоритмами могут найти подробный их обзор и сравнение .
Перечисленные выше трудности можно разрешить, если отказаться от равноправности всех клиентов и peer-to-peer соединений. При добавлении центрального сервера состояние документов можно описывать простой ревизией и требовать выполнения не более чем TP-1… Но этой теме будет посвящена уже следующая статья. Обещаю, что для любителей алгоритмов там будет больше интересного.