Older Newer
Never . . . . (Dmitry)?
Never . . . . (Dmitry)?
Never . . . . (Dmitry)?
Never . . . . (Dmitry)?
Never . . . . (Dmitry)?
Never . . . . (Dmitry)?
Never . . . . (Dmitry)?


Changes by last author:

Added:

== Принципы работы SyncML ==
Начнём с описания того, как работает SyncML, – XML-язык, описывающий принципы синхронизации контейнеров данных ("data-containers").

В обмене данными SyncML участвуют два типа контейнеров – клиент и сервер:
* сервер-контейнер разрешает конфликты данных;
* сервер-контейнер – не клиент. :)

В нашем случае, например, EGroupware – сервер; модильное устройство – клиент, но SyncML-сервер должен поддерживать такой клиент. В то же время SyncML-сервер EGroupware может выступать в роли клиента для другого SyncML-сервера, если он хорошо написан. Это интересно, если мы хотим синхронизовать сервера...
=== Рабочая сессия SyncML ===
Коротко:
# клиент отправляет серверу "ку-ку";
# сервер запрашивает данные аутентификации;
# клиент отправляет логин/пароль;
# сервер проверяет пару логин/пароль в EGroupware;
#* если логин/пароль неправильные, сервер отправляет клиенту: "Не авторизован";
#* если логин/пароль правильные, сервер отправляет клиенту: "OK, синхронизируемся медленно/нормально";
# клиент зарегистрирован?
#* если сервер распознаёт клиента, он запрашивает его "якоря" (anchors), то есть время последней синхронизации;
#* если сервер не распознаёт клиента, он выбирает медленную синхронизацию и переходит к шагу 8;
#* см. следующее описание или предыдущий шаг;
# клиент "бросает" серверу якоря (anchors);
# сервер проверяет якоря и:
#* если полученные от клиента якоря принадлежат серверу, он запрашивает нормальную синхронизацию;
#* если полученные якоря не отмечены, сервер запрашивает медленную синхронизацию;
# начало синхронизации
#* если синхронизация медленная, клиент отправляет все свои данные;
#* если синхронизация нормальная, клиент отправляет все свои добавленные/отредактированные/удалённые с момента прошлой синхронизации данные сообщая, что данные были добавлены/отредактированы и т.д.;
# сервер проверяет каждую, принятую от клиента, запись на конфликтность в отношении того, что есть на его стороне в смысле новизны/изменённости/удаления, распознавая таким образом новые/изменённые/удалённые данные, и отправляет все эти данные, которые клиент добавил/изменил/удалил, обратно клиенту;
# клиент узнаёт в принятых свои добавленные/изменённые/удалённые данные и закрывает сессию.

== Комментарии ==
Комментарии ожидаются.

----
Руководство пользователя / Синхронизация / Синхронизация. Обзор

Перевод на русский язык выполнен компанией "Мидл Бизнес Консалтинг Груп" (ЗАО "МБК Груп"), представляющей интересы правообладателя на территории РФ. С предложениями и замечаниями по русской версии документа обращайтесь по адресу: egw@mbcgroup.ru.