Comments 12
А почему не рассматривается вариант trans-user redo? То есть у вас же очередь изменений на сервере линейная, почему не разрешить пользователю А отменять изменения пользователя Б? Желательно, конечно при этом показывать, что произойдет и, если изменения не пересекаются, дать пользователю возможность отменять только те изменения, которые он сам внёс.
С точки зрения документа предложенный вами вариант (trans-user undo/redo) единственно правильный. Но с точки зрения пользователя так делать нельзя, потому что пока первый пользователь набирает что-то, второй захочет сделать Undo, но будет делаться Undo не тем действиям, каким он планировал, а тем, которые сейчас делает первый пользователь.Делать Undo только для непересекающихся действий тоже сомнительный вариант, потому что сделали мы три действия, например, а откатить можем только первое и третье. Это будет странно выглядеть для пользователя, что два раза Undo сработало, а один раз — нет.
Я себе представляю это так: Алиса редактирует абзац 1, Боб «одновременно» редактирует абзац 2. Алиса хочет сделать redo — поскольку у она не вносила изменения, которые пересекаются с Бобом — просто предлагаем Алисе откатить изменения в абзаце 1. Далее Алиса переносит предложение из абзаца 1 в абзац 2 и они с Бобом продолжают работать, внося еще изменения — Алиса в абзац 1, Боб — 2. Далее Боб решает откатить изменения и сначала система отменяет изменения которые он внёс в абзац 2, затем, когда черёд доходит до переноса предложения из абзаца 1 в абзац 2, Боб получает уведомление, что вот, мол, дальше откатить необходимо чужое изменение, при этом Бобу показывают, что случится, он соглашается, Алиса тоже получает апдейт.
Так можно сделать, но тогда быстрое совместное редактирование превратится в пошаговое, потому что чтобы Бобу добраться до изменения, которое он хочет откатить, нужно чтобы никто в этот момент больше в документе ничего не правил. Такое редактирование «быстрым» уже будет сложно назвать.
не в документе в целом, но в той его части, над которой работает Боб — да. Ну и блокировка не нужна, просто undo становится не совсем undo, а скорее "-do". В этом смысле лучше даже не как undo это представлять, а как историю изменений, в которой в любой момент можно отменить любое из них. То есть существует как бы две истории:
1. История версий документа, которая линейная и в которой понятия «undo» может и не быть, с точки зрения истории документа undo — это лишь противоположные действия добавленные в соотв. порядке, назовём их antidiff. В многопользовательской среде при этом могут параллельно добавляться другие изменения и вклиниваться между «undo».
2. С точки зрения пользователя существует история его действий (diff) «смешанная» с действиями других пользователей, если они вносили изменения в те блоки, где работал пользователь. Пользователь мог бы иметь возможность откатывать эти действия, при этом в истории версий документа действия только лишь добавляются. Во множестве случаев результат такого «undo» будет аналогичен Ворду.
Блокировка требуется только в том случае, если кто-то решить откатится на старую версию в дереве номер 1. Такую возможно тоже можно добавить, мне кажется. При этом, конечно, желательно отменённые изменения из дерева 1 сохранять как рид-онли ветки.
1. История версий документа, которая линейная и в которой понятия «undo» может и не быть, с точки зрения истории документа undo — это лишь противоположные действия добавленные в соотв. порядке, назовём их antidiff. В многопользовательской среде при этом могут параллельно добавляться другие изменения и вклиниваться между «undo».
2. С точки зрения пользователя существует история его действий (diff) «смешанная» с действиями других пользователей, если они вносили изменения в те блоки, где работал пользователь. Пользователь мог бы иметь возможность откатывать эти действия, при этом в истории версий документа действия только лишь добавляются. Во множестве случаев результат такого «undo» будет аналогичен Ворду.
Блокировка требуется только в том случае, если кто-то решить откатится на старую версию в дереве номер 1. Такую возможно тоже можно добавить, мне кажется. При этом, конечно, желательно отменённые изменения из дерева 1 сохранять как рид-онли ветки.
Статье не хватает технических подробностей, без них она выглядит как промо-материал «какие мы молодцы, что сделали то, что хотели наши клиенты».
Например, какая у вас статистика запросов; сколько у вас серверов, чтобы выдерживать обновления каждые 1/25 сек.; какой стек технологий используется для реализации; etc…
Например, какая у вас статистика запросов; сколько у вас серверов, чтобы выдерживать обновления каждые 1/25 сек.; какой стек технологий используется для реализации; etc…
OpenSource версии редакторов уже поддерживают этот функционал? Можно обновляться?
меню «Файл» — вкладка «Дополнительные параметры» — «Co-editing mode».
Либо все английским, либо всё по-русски.
Sign up to leave a comment.
Что ж, этот день настал: быстрое совместное редактирование в редакторах ONLYOFFICE