Тему первой статьи подсказала нам сама жизнь. Не так давно наравне с вопросом: «А чем вы лучше Google Docs?» нам начали задавать вопрос «Ну и чем вы лучше Collabora?». Это связано с нашей интеграцией с сервисами ownCloud и Nextcloud, официальным партнером которых как раз таки является Collabora.
Если говорить о преимуществах, то у Collabora есть перед нами очень большое — идеологическое. Оно заключается в том, что этот продукт является продолжателем дела OpenOffice и LibreOffice. Непросто бороться с ними за пользователей, но у нас есть весомые аргументы в свою пользу. Сейчас расскажем.
Где редактор? Краткий экскурс в анатомию Collabora и ONLYOFFICE
Collabora — это представление редактора, открытого на сервере, в вашем браузере. И этот редактор — LibreOffice. Во многом поведение Collabora напоминает «тонкий клиент», потому что у вас на компьютере почти ничего не происходит. Всё волшебство происходит исключительно на сервере. Правда, есть одно отличие — Collabora не выглядит в точности как LibreOffice, у неё есть собственный интерфейс (мы вернемся к нему позже).
В ONLYOFFICE мы стараемся задействовать именно ресурсы клиента. То есть, редактор действительно работает у вас в браузере, просто периодически он обменивается данными с сервером. Если в Collabora на сервере происходит чуть более, чем всё, то у нас на сервере происходит всего несколько процессов, в числе которых сохранение, конвертация и проверка орфографии. Это позволяет экономить ресурсы сервера и работать быстрее.
Об отрисовке и наборе текста
Заметить, как устроена отрисовка в Collabora несложно. Страница разбита на блоки, это позволяет ей загружаться быстрее (вы же помните, что эти картинки вам приходят с сервера?). Но интернет — штука хитрая, поэтому некоторые из них могут подгружаться медленнее или не прогружаться совсем. Нам при тестировании этого продукта доводилось смотреть на серые пятна.
В целом устройство Collabora предполагает некоторое природное замедление: редактор находится на сервере, он оторван от пользователя. Тот курсор, который мы видим на экране, на самом деле, не тот курсор, который стоит в редакторе. Между ними есть задержка — отправка координат. Вы видите просто картинку из редактора.
ONLYOFFICE — это полноценный редактор в браузере. Мы полностью обрабатываем все события пользователя на клиенте и отправляем информацию о них на сервер. Получается гораздо оперативнее.
Функциональность: о потенциальном и реальном
Наследие LibreOffice — это значительное преимущество Collabora. Её разработчикам не надо писать все функции заново, у них автоматически есть всё, что есть в Libre. Другими словами, оглавление* у них было раньше, чем сам продукт (с 2003-го примерно).
*и тут вы 100% вспомните нам, что у нас вот, например, нет оглавления до сих пор. Мы советуем вам быстро это сделать прямо сейчас, пока не поздно. Потому что жить этой претензии осталось недолго.
На самом деле, радоваться всё равно рано: мы уже упоминали, что у Collabora свой собственный веб-интерфейс, и в него пока протащили далеко не всё. Вы не можете добавить не то что оглавление, но даже банальную автофигуру или диаграмму. В общем, несмотря на то, что открытие документов у Collabora сейчас на уровне десктопной Libre, возможности редактирования у неё пока исключительно базовые. Потому что, видимо, нет функциональности — нет проблем*
*но мы пошли другим путем
Знаете, бывают такие мероприятия, где мы представляем редакторы ONLYOFFICE и нас спрашивают что-то вроде: а можно ли у вас поменять шрифт или выделить текст жирным? Мы расстраиваемся и просим дать нам задачку потруднее, потому что давно прошли этот этап — добавили все возможные объекты, красивые диаграммы, работу с автофигурами и формулами. Сейчас доделываем оглавление, сводные таблицы (они сейчас открываются только на просмотр) и цифровую подпись.
Проблемы с совместимостью в наследство
Здесь всё понятно: Collabora получила в качестве наследства все проблемы и баги Libre. И главная проблема тут — плохая совместимость (очень) с форматами Microsoft. Как мы помним, то, что майкрософтовские форматы OOXML (docx, xlsx, pptx) — родственники форматов OpenDocument, не прибавляет им совместимости.
Хотя, конечно, если вы и все, с кем вам доводится работать, остаетесь верны ODF, то для вас это не будет проблемой. Это будет проблемой для тех, кто откровенно предпочитает Microsoft, или же работает с широким кругом документов из разных источников. Им (особенно первым) Collabora не подойдет.
Напомним, что большинство документов на этой планете привязано к docx, xlsx и pptx. Как бы мы ни восхищались открытыми офисными пакетами, Microsoft — по-прежнему мировой лидер и их редакторы по-прежнему стоят повсюду и сохраняют документы именно в такие форматы с 2007 года.
В ONLYOFFICE мы используем форматы docx, xlsx и pptx в качестве базовых, потому что мы хотим отлично открывать большую часть документов, а не меньшую. И да — мы точно откроем такие документы в миллион раз лучше, чем Collabora (и Libre). Это наша работа, мы специализируемся на этих форматах.
Работаем ли мы с ODF? Да, но конвертируем. И качество конвертации постоянно растет.
Архитектура: почему использовать Collabora — это дорого?
В основном потому, что она задействует ресурсы сервера. Это главный минус того, чтобы просто запустить на сервере редактор и всех к нему подключать. В конце концов, если бы это было выгодно, то эту схему давно использовали бы Вы-Знаете-Кто*.
(*Microsoft)
Поясним: вы открываете документ и он занимает 500 Мб памяти (и при этом еще может увеличивать расход в процессе форматирования). Потом ваш коллега открывает свой документ — ещё минус 500 Мб памяти. А если кто-то откроет документ в 700 страниц — ещё минус 1,5 Гб. Сколько памяти и серверов вам потребуется, чтобы покрыть потребности своей команды? Можно посчитать: если у вас два ядра и два гигабайта памяти на каждое из них, то вам хватит этого на 8-10 человек. А если у вас еще +8-10 человек, то вам уже нужен второй сервер.
Можно пытаться что-то оптимизировать, например, использовать одно общее ядро для запуска, но документ все равно записывается в память — в память сервера в случае Collabora.
Схема, которую выбрали разработчики Collabora, просто пожирает ваши ресурсы. Если у вас большая компания, то с таким офисом вам придется заниматься исключительно серваками: их потребуется много и необходимо будет постоянно балансировать между ними нагрузку, потому что клиенты не должны мешать друг другу (но они будут).
Возможности балансировки не бесконечны, хотя бы потому, что в такой схеме клиент привязывается к серверу. Главная привязка тут — совместное редактирование. Например, вы приглашаете коллегу присоединится к редактированию отчета, над которым вы сейчас работаете. Отлично, но в схеме Collabora ему нужно зайти в тот же редактор на том же сервере, на котором вы сейчас. И неважно, что на нём ещё 10 человек правят свои документы, понимаете куда мы клоним? Вы будете мешать друг другу и всё будет тормозить.
Конечно, в Collabora пытаются как-то нивелировать это всё и экономить память. Например, вы можете заметить, что открытый документ, который вы некоторое время не трогаете, становится неактивным. Пока он неактивен, там не проходит автосохранение, изменения не подгружаются. Экономия.
Архитектура ONLYOFFICE: почему это оптимальнее?
Потому что мы используем вычислительные ресурсы клиента, а не сервера. Конечно, мы расходуем серверные ресурсы тоже, но в существенно меньшей степени, чем Collabora. Связь между клиентом и сервером поддерживается, но незначительная. Тестирование (и практика) показывает, что на сервере (возьмем, например, с процессором семейства Intel Core i5) с развернутым ONLYOFFICE мы комфортно может позволить себе 75 пользователей (точнее, 75 открытых вкладок с редакторами) на ядро.
Таким образом, на гипотетической машине с двумя ядрами в Collabora смогут работать только 8-10 пользователей, а в ONLYOFFICE — 150.
Совместное редактирование: боль или радость
В Collabora появилось совместное редактирование. Оно основано на том, что редактирующие заходят в один редактор на одном сервере. С этим связано вот какое неудобство: есть вещи, которые включаются для всего документа. То есть, если вы вдвоем в документе в Collabora и кто-то включает Track Changes, то Track Changes включается для всех. И вы не сможете этого избежать. Возможно, поэтому в Collabora пока нет непечатаемых символов.
В ONLYOFFICE такого в принципе не произойдет: у вас в браузере действительно работает полноценный редактор, и это полностью ваше пространство, где вы можете включать и выключать Track Changes, не вторгаясь ни в чье личное пространство. И не только Track Changes.
Что вы хотите сделать, когда нажимаете undo?
Другой момент в совместной работе в Collabora — устройство undo/redo. Вот вы что хотите, когда нажимаете ctrl-z? Предполагаем, что, как и любой здравомыслящий человек, вы хотите отменить СВОЁ последнее действие. Посмотрим, как устроена undo в наших редакторах, чтобы понять, сможем ли мы достичь этой цели.
В Collabora undo/redo сквозное для всего документа. Рассмотрим ситуацию:
Пользователь 1 вводит букву «А»
Пользователь 2 вводит букву «Б»
Пользователь 1 хочет отменить букву «А». Он не сможет это сделать. Кнопка Undo будет активна только у второго пользователя, потому что последнее действие принадлежало ему. В общем, бедняга Пользователь 1 так и не сможет отменить своё последнее действие, пока Пользователь 2 не отменит своё последнее действие, то есть букву «Б». Это означает, что в Collabora нет разницы, совместное редактирование или нет, главное — откатывать изменения в той последовательности, в которой они поступали в документ.
Благодаря такой схеме undo/redo рождаются такие магические моменты, когда вы вроде бы ничего не делаете, но при этом в тулбаре происходят изменения: как, например, у Пользователя 1, когда Пользователь 2 отметил букву Б, сразу стала активной кнопка undo. Вроде бы пустячок, а получается как будто то, что происходит у вас в редакторе, зависит не от вас, а от каких-то внешних факторов.
Что касается ONLYOFFICE, то вы сможете отменить своё последнее действие в любом из режимов совместного редактирования (у нас их два, подробнее в этой статье). Как нам это удается? В основном, потому что мы почти всё делаем на клиенте. Там же хранится список действий — не только своих, но и чужих. Свои собственные действия помечаются, чтобы потом была возможность их откатить. Сервер при этом используется как база данных, с помощью которой мы синхронизируем правки на клиентах. Технические подробности реализации мы уже описывали вот тут. Самое главное отличие реализаций undo/redo — у нас оно работает «от пользователя», а у Collabora — «от документа».
Краткие выводы
- Collabora лучше, чем ONLYOFFICE открывает документы OpenDocument, но гораздо хуже открывает OOXML (docx, xlsx, pptx).
- Функциональность ONLYOFFICE на данный момент шире, чем функциональность Collabora. Но в Collabora потенциально есть все фичи, которые есть в Libre.
- На одном сервере с 2-мя ядрами смогут одновременно работать 8-10 пользователей, если на нём развернута Collabora, или 150 пользователей, если на нём установлен ONLYOFFICE.
- В Collabora обработка всех действий от пользователя происходит на сервере, в ONLYOFFICE — на клиенте.
- Collabora работает медленнее, это издержки архитектуры.
- Совместное редактирование в Collabora основано на том, что пользователи заходят в один документ в одном и том же редакторе, что порождает ряд неудобств.
- В ONLYOFFICE у каждого пользователя свой полноценный редактор в браузере. Сервер используется как БД для хранения пользовательских правок и последующей сборки файла.
Вы можете сделать свои выводы или рассмотреть аспекты, которые мы упустили. Но знаете что? По нашему мнению, пока что Collabora — продукт медленный (это решается хорошим интернетом), сырой (но можно доработать), с большим количеством багом (но их, конечно, пофиксят), но самое главное — их архитектура экономически невыгодна и к этому подорожник не приложишь, в то время как ONLYOFFICE можно использовать уже сейчас. Начать можно, например, с нашего решения для интеграции со сторонними облачными сервисами, такими как Nextcloud и ownCloud.
P.S. Кстати, мы недавно выпустили редакторы ONLYOFFICE c переработанным интерфейсом, в котором инструменты сгруппированы в тематические вкладки. Это позволило нам облегчить навигацию по инструментам редактора, а ещё сделать видимыми многие важные вещи — например, плагины (про них скоро расскажем отдельно). Как выглядит новый интерфейс и что стало где в этом видео.
Комментарии (40)
Am0ralist
07.11.2017 16:38-1Здесь всё понятно: Collabora получила в качестве наследства все проблемы и баги Libre. И главная проблема тут — плохая совместимость (очень) с форматами Microsoft. Как мы помним, то, что майкрософтовские форматы OOXML (docx, xlsx, pptx) — родственники форматов OpenDocument, не прибавляет им совместимости.
Работаем ли мы с ODF? Да, но конвертируем. И качество конвертации постоянно растет.
Главная проблема, что полноценная «конвертация» тех же формул невозможна из-за кучи нюансов поведения.
Так как там разница уровня ="" в ООо обработается как ноль в математической формуле, а в экселе — выдаст ошибку. Или что при объединении ячеек в ООо запросто можно сохранить данные в скрытых ячейках (если при объединении ячеек данные не были слиты вместе в первую) и к ним можно обращаться, а в экселе они теряются.
Как это можно сохранять, конвертируя документы туда/сюда мне лично не понятно.
trofim24
07.11.2017 17:29OOXML не запрещает писать данные в ячейки, «скрытые» при помощи merge. Microsoft просто не предоставляет такой возможности в интерфейсе, как и мы. OpenOffice же предлагает выбор. Поэтому у нас не возникает проблем при конвертации таких файлов.
Про формулу ="" не совсем понятно, что имелось ввиду, у меня во всех редакторах ошибка "#VALUE!".Am0ralist
07.11.2017 18:12В A2 пишем ="", т.е. присваиваем формуле значение 'пусто' (например, удобно не отображать нули if(a1>0;a1*2;""))
Если в другую написать =A2*1, получаем в ООо — 0 (более того, даже =""*1 даст ноль на выходе), в Excel — #ЗНАЧ!
Причем если в ячейке реально пусто, а не формулой задано, то и там, и там считает 0.
Так вот, если принять какую-то сторону, то это автоматически приводит к ошибкам при работе с другим форматом, так как люди пишут свои формулы под именно такое поведение. Либо добавлять костыли с анализом, какой в реальности формат поступил на вход вашей программы.
Таких мин раскидано много. И, кстати, я уже спрашивал в личку, как и про — у вас есть таблица сравнений разницы между функциями в OOo и Excel, но ответа не получил.
Ещё лучше б, если б это была а-ля вики с возможностью дополнения пользователями, вам же самим проще было бы соломку стелить.
nickneo
07.11.2017 20:12хм… в LibreOffice выдает #ЗНАЧЕН!
Am0ralist
07.11.2017 22:23Вот за это, если честно, я не люблю форки. В ООо такое поведение было с 3 версии.
Обратная совместимость? Да зачем она нужна! Кому надо форкнут форк, опенсурс же…
А вот в гугло таблицах ровно то же поведение, как и в OOo.
Что логично. Пустая ячейка независимо от формата = 0, а если в значение записали пустую строку — то вдруг уже не равно нулю? Ну, тогда бы и на отсутствие значения ошибку бы писали…nickneo
08.11.2017 10:32Ну, я так понимаю, все остальные Офисы переняли такое поведение, как раз, для совместимости. Один OpenOffice ведет себя по другому. Да, и не проще ли, скрывать отображение нулевых значений через формат ячеек? Вроде такого Формат ячеек > Тип: 0;-0;;@
Am0ralist
09.11.2017 14:25все остальные Офисы переняли такое поведение, как раз, для совместимости
Ну вот привел в пример гугловские таблицы. Так что не все.
Правильно, надо перенимать совместимость с другими ломая с своими старыми…
Да, и не проще ли, скрывать отображение нулевых значений через формат ячеек? Вроде такого Формат ячеек > Тип: 0;-0;;@
В зависимости от задач. Задача может стоять и уровня отображать все, в том числе и ноль, если в другой ячейке не пусто, а если там пусто — ничего не отображать. Только в итоге уже на эту ячейку ссылается подсчет в третьей, который будет выдавать ошибку или. То есть решить вопрос — можно. Однако как это поможет при открытии уже созданного документа в данном софте (и да, привет либере за это!)
А условной форматирование — дико не удобный инструмент при большом количестве строк/ячеек, где подобное поведение нужно. Список уж больно большой получится таких стилей и надо будет как-то привязку к ячейкам в названии, чтоб понимать где что, а ячейки — сдвигаются бывает.
Другой вопрос, что это не единственное отличие.
Например, сколько можно вложений функций делать в разных функциях экселя? Раньше было не так уж и много (а в последних версиях я просто не пробовал), а в ООо их реально десятками вкладывал в друг друга.
sHaggY_caT
07.11.2017 18:27+2Странно сравнивать проприетарное решение и OpenSource. ИМХО, Ваш главный конкурент гугл докс. С ним и нужно сравнивать.
VolCh
07.11.2017 20:35Ничего странного. Мало кто выбирает пользовательский софт по идеологическим соображениям.
hellonadya
08.11.2017 10:14В этой статье мы сравниваем два open source решения. Исходный код ONLYOFFICE открыт. Вы можете найти его на гитхабе. Что касается сравнения с Google Docs, мы уже писали о нём.
sHaggY_caT
08.11.2017 13:02Тогда извините. Может, стоит поместить информацию об этом на Вашем сайте на более видное место?
lobzanoff
07.11.2017 19:29Пробовал OnlyOffice десктопный, который без сервера — оч. понравился, и у меня вопрос — автоматической расстановки переносов нет вообще или только бесплатной бессерверной системы? И если планируется, то в насколько дальней перспективе? Очень злободневно для написания документации.
lmike
07.11.2017 20:16Collabora лучше, чем ONLYOFFICE открывает документы OpenDocument, но гораздо хуже открывает OOXML (docx, xlsx, pptx).
любой документ docx, xlsx...?
хорошо бы «типичные» примеры документов выложить, что бы можно было судить — насколько критично это «хуже»hellonadya
08.11.2017 10:30В принципе, любой. ONLYOFFICE такие документы откроет как свои, потому что для нас эти форматы являются базовыми. Collabora в любом случае будет конвертить в свой нативный формат. OOXML и ODF, конечно, оба XML, но вообще это будет песнь льда и пламени, потому что между собой они не особо совместимы.
За идею с документами спасибо. Постараемся сделать нечто подобное. А сейчас у нас есть вот такие презентации со сравнениями, там по открытию есть информация.
Jon7
07.11.2017 22:06А если кто-то откроет документ в 700 страниц — ещё минус 1,5 Гб.
Вы считаете, что обрабатывать документы такого размера, что на сервере, что в браузере, это здоровая практика?
Проясните Вашу позицию по способам обработки документов подобного размера, она не понятна. Каким образом можно продуктивно использовать универсальный инструмент для создания и поддержания таких документов.
xkorolx Автор
07.11.2017 22:08Практика нездоровая. Но одно дело так напрягать клиент (собственно и открывший этот документ), а другое сервер.
Am0ralist
07.11.2017 22:30Поверьте, 1,5 гига я вам устрою и не на 700 страницах.
Хватит формул на несколько мегабайт. А с учетом, что стандартно хранится история на сотни шагов, то при глобальных изменениях объем, занимаемый документом в оперативке — станет космический. И это в том же ООо, установленном на локальном компьютере.
обрабатывать документы такого размера, что на сервере, что в браузере, это здоровая практика?
После приведенных примеров, чем браузер хуже спец.редактора?Jon7
08.11.2017 11:54После приведенных примеров, чем браузер хуже спец.редактора?
Не правильно задан вопрос. В данном случае спец редактор располагается либо на сервере либо в браузере, ну да ладно. Суть дела в другом. В случае с такими большими документами плох сам подход, негодный выбор технологии. Поясню подробнее.
Какая идеология заложена у MSO. Он ориентирован на обработку информации которая быстро теряет свою актуальность, такие данные используются в первую очередь в финансово-экономической области, где жесткие сроки по отчетности, информация меняется непрерывно. Вот цепочка действий на которую «заточен» MSO: access в качестве коннектора/прокси/словарей для извлечения данных из большой БД -> exel для анализа данных -> word для составления заключения -> powerpoint для наглядного пояснения сути дела начальству -> outlook для рассылки и обратной связи.
OpenOffice более заточен для создания научных статей, период актуальности информации существенно больше, данные меняются намного более медленно, провел эксперимент записал, следующий эксперимент когда ещё будет. Поэтому open/libre office сильнее с стилями оформления, но слабее с таблицами, информация меняется редко, частые смены не актуальны.
Данные аспекты в разнице предметных областей вообще никак не учитываются, но и это ещё не все.
Документ в 700 страниц, согласитесь, это фактически книга. А к написанию и изданию книг человечество выработала другой подход, другие технологии. В издательском деле актуально разделить действия на группы текст, художественное оформление, корректура, верстка, печать. Такой подход доказал свою состоятельность. А что мы имеем здесь, каша, все свалено в одну кучу.
Именно поэтому я и просил разъяснить позицию автора, непонятно зачем смешивать вместе, в чем суть такого смешения.Am0ralist
09.11.2017 14:37Документ в 700 страниц, согласитесь, это фактически книга.
Это может быть тупо выписка из реестра (тысяч сто строчек из экселя, которые нужно вставить в вордовский документ по требованию заказчика, реальный кейс из оценки). Объем страниц ничего не говорит про содержимое.
. А к написанию и изданию книг человечество выработала другой подход, другие технологии. В издательском деле актуально разделить действия на группы текст, художественное оформление, корректура, верстка, печать. Такой подход доказал свою состоятельность. А что мы имеем здесь, каша, все свалено в одну кучу.
И как это связано к изначальному:
Вы считаете, что обрабатывать документы такого размера, что на сервере, что в браузере, это здоровая практика?
То есть изначально вас интересовала работа именно на сервере или в браузере, а сейчас вы рассуждаете об заточенных под конкретную задачу решениях. А что мешает те же решения реализовать на сервере или в браузере, мне не понятно? Ну вот будет у нас в бразуере десяток решений отдельно для оформления, отдельно для корректуры, отдельно для верстки и т.п. — в чем проблема? Тут в браузере даже фотошопы реализовывают, что, тоже запретить?
robux
08.11.2017 01:30Редактировать документы нужно в десктопных редакторах (LibreOffice, MSOffice и т.п.).
Браузер должен служить только для отображения веб-страниц (новости, интернет-магазин, форумы и т.п.).
Использовать браузер ДЛЯ ВСЕГО-НА-СВЕТЕ (в том числе, чтобы плодить корпоративных рабов) — 1) негуманно, 2) уродливо.
У меня всё.VolCh
08.11.2017 09:26Редактировать документы нужно там, где это удобно и эффективно. Рынок предлагает разные варианты, для разных потребностей и вкусов. Может быть в итоге останется только один, но вряд ли это будет десктопное приложение, запускаемое на локальной машине пользователя.
Am0ralist
08.11.2017 09:51Скажите, у вас ведь до сих пор кнопочный телефон без проигрывания mp3, камеры и интернета?
gt8one
08.11.2017 08:16Сделайте ещё сравнение с МойОфис (Collabio Office)
hellonadya
08.11.2017 10:22Обязательно сделаем в будущем! Пока они не предоставляют свободного доступа к продукту. А вообще было бы здорово, если бы такое сравнение писали сами пользователи, у которых уже была возможность потестировать его.
hard_sign
08.11.2017 12:09Вот кстати, если вы всерьёз хотите конкурировать с MSOffice, позаботьтесь о том, чтобы работали клавиатурные сокращения. Я пытаюсь пользоваться таблицей DesktopEditors, но мне очень не хватает Ctrl+1, Ctrl++, Ctrl+-, Ctrl+D и т. д.
Доработка копеечная, но очень поможет в пересадке пользователей, особенно опытных.
nukler
08.11.2017 12:09Когда тестировали был шок, что Ваш продукт рассылает письма сотрудникам с рекламой.
Ну то есть он у нас живет своей жизнью, что то сам там делает, пишет письма и прочее (а вот что прочее??).
Это руководству сразу не понравилось и была поставлена точка.hellonadya
08.11.2017 12:41Уточните, пожалуйста, о каком продукте идет речь?
Мы действительно оставляем за собой право уведомлять пользователей о выходе новых версий и акциях ONLYOFFICE. Никакой сторонней рекламы мы не распространяем. При желании от рассылки можно отписаться.
lmike
08.11.2017 12:33В Collabora обработка всех действий от пользователя происходит на сервере, в ONLYOFFICE — на клиенте.
я не считаю это недостатком
все зависит от организации взаимодействия с сервером, с случае с ONLYOFFICE взаимодействие тоже необходимо
Collabora работает медленнее, это издержки архитектуры.
может издержки конкретной реализации?
Давайте представим, что к-л продукт «грамотно» рендерит ту часть, с которой работает пользователь и не тянет весь контент на клиента, и не занимает место в памяти сервера, размещая там весь документ. Сервер будет «знать» — с какими частями работает «какой» клиент
В случае с клиентским кодом, если надо вытянуть весь док на клиента и потом его синхронизировать с состоянием на сервере..., мне кажется — куча доп. работы и нагрузка на каналы
Как пример… Сейчас наблюдаю работу «документооборота»..., в его реализации есть локальный клиент, мало того что от отжирает 300 Мб памяти, еще без к-л деятельности, он еще и документы «пописывает» на стороне клиента, а для этого — выгружает док сервера/подписывает/загружает. Для объемных документов — это жутки тормоза и время ожидания.
Второй момент: при открытии/закрытии документа одним клиентом, состояние блокировки не всегда обновляется корректно на сервере (возможно из-за сетевых задержек), как результат — другой клиент не может «ничего» сделать с этим документом и 1-му надо закрыть все приложение!xkorolx Автор
08.11.2017 12:53Мы считаем, что чем меньше нагрузка на сервер — тем лучше. Так как если пользователь работает с документом — странно передавать (через сервер) эти тормоза человеку, который работает на этом же сервере, но с другим документом. Много людей — потребуется много серверов, а это не выгодно. И, по-нашему мнению, Collabora так поступает лишь по одной причине — потому что у них нет браузерного редактора. И совместного редактирования тоже нет. И был выбран максимально простой вариант — открывать Либру на сервере и транслировать мышь и клавиатуру пользователей. Рабочий вариант, никто не спорит. Но уж точно не «грамотный».
lmike
08.11.2017 14:22Collabora так поступает лишь по одной причине — потому что у них нет браузерного редактора. И совместного редактирования тоже нет. И был выбран максимально простой вариант — открывать Либру на сервере
в приведенном куске вами «осуждался» подход к обработке на сервере
Еще момент: не факт, что либра не сможет, в будущем, предоставлять более гибкие средства взаимодействия (в контексте запуска отдельных процессов и оверхеда по памяти)
Нагрузка на сервер, безусловно, важна и если разбирать Collabora и либре — есть куда стремиться. Но упор на преимущество подхода «исполнения на клиенте», для меня, не звучит убедительно
Добавим тезис о популярности docx и прочих проприетарных форматов…
Ситуация: фирма1 присылает фирме2 документ на согласование/правку, в большинстве случаев согласовывают содержание, а не форму. Учтем еще — каждая организация имеет свой свод «корпоративных» стандартов. Конечный документ будет не в редактируемом виде (скорее-всего хардкопия) и в электронном виде — PDF вполне кандидат на данную роль. Как у вас обстоит дело с сохранением верстки при конвертации в PDF средствами ONLYFFICE?
Меня вполне устраивало качество конвертации docx в PDF либрой (с учетом граблей оформления в МСО)
Т.о. интересуют возможности оформления документов (присутствующие в продукте), а не формат. Выходной формат, самый распространенный — PDFxkorolx Автор
08.11.2017 14:29У нас четкое разграничение в редакторах. Логическая (форматная) часть -> измерение -> отрисовка. И сохранение в пдф — это просто подмена отрисовщика на канве/нативного на сохранялку в пдф. Поэтому сохранение в пдф 1-в-1 так, как вы видите в редакторе документ. Согласен на 100%, что если файл не для редактирования и его надо передавать — то только PDF. Чтобы со встроенными шрифтами и без багов/особенностей измерятеля.
Am0ralist
09.11.2017 14:43В Collabora обработка всех действий от пользователя происходит на сервере, в ONLYOFFICE — на клиенте.
я не считаю это недостатком
Могу привести ООо в пример. Берем «большой» файл, который в оперативке занимает метров 300. Ок, удаляем страничку с кучей данных. В оперативке еще +300 метров сожралось, так как история откатывать обязана шагов на сто назад документ, да еще типа того шустро. Продолжаем еще так делать раз десять и опа, ООо упал, выжрав гига полтора. Это на локальной машинке. На сервере таких пользователей может оказаться несколько, каждый выжрет по паре гигов и?lmike
10.11.2017 13:58LO тоже так делает? Надеюсь баг зафиксировали ;)
повторюсь… обработка на сервере (как подход к архитектуре приложения) я не считаю недостатком.
То что ошибки приложения есть — это не повод «ругать» архитектуруAm0ralist
10.11.2017 23:27LO тоже так делает?
да может и последний ООо уже так не делает, если честно. Ибо более двух лет назад сталкивался с подобным поведением.
Надеюсь баг зафиксировали ;)
Я, не являясь тестировщиком в полной мере в среднем за день сталкиваюсь с парочкой новых багов в разных приложениях. В особо плохие дни — с десятками. За пару дней — четыре тикета в мантисе. Да меня только фиксация багов в нужных приложениях уже достала, что бы тратить еще полжизни на фиксацию во всех подряд, да еще с проверкой, где они повторятся, а где нет. Вначале бы свернули деятельность по распылению на форки, а то выяснилось, что файл свободного формата .ods созданный в опенсурном же ООо может не верно работать в его форке Либре — офигенчик же, я считаю.
обработка на сервере (как подход к архитектуре приложения) я не считаю недостатком.
обработка на сервере таких вещей может являться большой нагрузкой на серверы, особенно с учетом того, как эти приложения пишут. В этом плане возложить на локальную машину, которая чаще всего сейчас может позволить себе подобные «излишки» (вспоминая требования того же 97 офиса, возможностей которого большинству за глаза) — это отличный вариант.
PS. С другой стороны мне вспоминается клиент зимбры на джаве (если не ошибаюсь), который установленный локально вызывал дичайшие тормоза системы на всех компьютерах фирмы, после чего всех перевели в браузер и вуаля, проблемы тормозов исчезли… С другой стороны, если бы выбрали запуск данного клиента на сервере и трансляцию мыши и клавиатуры пользователю (с) — сервер бы, скорей всего, сдох в максимальных мучениях.
Areso
08.11.2017 15:30Файл, выгруженный из БД, csv, 4.5 мегабайта. Ни оформления, ни формул. 5 тысяч строк, около 30 полей.
LibreOffice: 35 мегабайт ОЗУ
ONLYOFFICE: 240 мегабайт ОЗУ (потребление браузера)
Collabora: не открыл файл. Файлик поменьше сожрал 190 метров (потребление браузера).
Потребление бэка на демо-доступах не отображалось.
Веду учет расходов в onedrive табличном редакторе. Примерно на двух тысячах строчках оно начинает лагать. В результате стал делить на периоды, не реже чем раз в год начинать новый лист.
Diaskhan
Если бы у onlyoffice был электронный документооборот вы убили бы sharepoint! Посмотрите в сторону ельмы бпм! У вас вполне готовая экосистема для полного покрытия стека enterprise!
hellonadya
В документообороте нам действительно есть над чем поработать. Спасибо.