Как создать высокоуровневый протокол приложений и формат данных для синхронизации метаданных между устройствами и сервером?

Question

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

Моя цель: пользователь может взаимодействовать с данными приложения на любом устройстве или в Интернете. Цель этого протокола - обменивать изменения, сделанные на одной конечной точке, на другие конечные точки через сервер и обеспечивать, чтобы все устройства поддерживали согласованное изображение данных приложения. Если пользователь вносит изменения на одном устройстве или в Интернете, протокол будет передавать данные в центральный репозиторий, откуда другие устройства могут его вытащить.

Некоторые другие конструктивные мысли:

• Я называю это «метаданные синхронизации», потому что полезная нагрузка будет очень небольшой, в виде идентификаторов объектов и малых метаданных об этих идентификаторов. Когда конечные точки клиента извлекают новые метаданные по этому протоколу, они будут извлекать фактические данные объекта из внешнего источника на основе этих метаданных. Извлечение «реальных» данных объекта выходит за рамки, я говорю только о синхронизации метаданных.
• Использование HTTP для транспорта и JSON для контейнера полезной нагрузки. Вопрос в основном заключается в том, как наилучшим образом разработать схему полезной нагрузки JSON.
• Я хочу, чтобы это было легко реализовать и обслуживать в Интернете и на настольных и мобильных устройствах. Лучший подход - быть простым HTTP-запросом/ответом на основе таймера или событий без каких-либо постоянных каналов. Кроме того, у вас не должно быть PhD, чтобы прочитать его, и я хочу, чтобы моя спецификация помещалась на 2 страницы, а не 200.
• Аутентификация и безопасность не подходят для этого вопроса: предположим, что запросы являются безопасными и аутентифицированными.
• Целью является конечная согласованность данных на устройствах, она не является полностью реальной. Например, пользователь может вносить изменения на одном устройстве во время автономной работы. При повторном входе в систему пользователь выполнит операцию «sync» для локальных изменений и получения удаленных изменений.
• Сказав, что протокол должен поддерживать оба эти режимы работы:
  • Начиная с нуля на устройстве, должно быть в состоянии вывести всю картину метаданных
  • «синхронизацию, как вы идете». Когда вы смотрите на данные на двух устройствах рядом друг с другом и вносите изменения, нужно легко нажимать эти изменения как короткие индивидуальные сообщения, которые другое устройство может получать почти в реальном времени (при условии, когда оно решит связаться с сервером для синхронизации).

В качестве конкретного примера, вы можете думать о Dropbox (это не то, что я работаю, но это помогает понять модель): на ряде устройств, пользователь может управлять им файлы и папки - перемещайте их, создавайте новые, удаляйте старые и т. д. И в моем контексте «метаданные» будут структурой файлов и папок, но не фактическим содержимым файла. И поля метаданных будут чем-то вроде имени файла/папки и времени модификации (все устройства должны увидеть одно и то же время модификации).

Другим примером является IMAP. Я не читал протокол, но мои цели (минус фактические тела сообщений) одинаковы.

ощущению как есть два великих подхода, как это делается:

• транзакционных сообщений. Каждое изменение в системе выражается как дельта, а конечные точки общаются с этими дельтами.Пример: изменения в DVCS.
• REST: передача объекта в целом или частично, не беспокоясь об отдельных изменениях атома.

EDIT: некоторые из ответов справедливо говорят, что нет достаточно информации о приложении, чтобы предложить достаточно хорошие предложения. Точная природа приложения может отвлекать, но очень простое приложение для чтения RSS - достаточно хорошее приближение. Итак, скажем, спецификация приложения следующая:

• Существует два класса: фиды и предметы.
• Я могу добавлять, переименовывать и удалять каналы. Добавление фида подписывается на него и начинает получать элементы для этого фида. Я также могу изменить порядок отображения каналов в пользовательском интерфейсе.
• Поскольку я читал предметы, они помечены как прочитанные. Я не могу пометить их непрочитанными или сделать с ними что-нибудь еще.
• На основании вышеизложенного, объектная модель:
  • «кормить» имеет атрибуты «URL», «DisplayName» и «displayOrder» (displayOrder является индексом корма в списке UI о кормах, переназначения каналов локально изменяет displayOrder всех каналов, чтобы индексы оставались уникальными и последовательными).
  • «item» имеет атрибуты «url» и «непрочитанные», а отношение «один» - «один» принадлежит каждому элементу. «url» также ведет себя как GUID для элемента.
  • Содержимое фактического содержимого загружается локально на каждом устройстве и не является частью синхронизации.

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

(конец редактирования)

Что я хотел бы в ответах:

• Что важно, чтобы я оставил выше? Ограничения, цели?
• Что это за хороший фон? (Я понимаю, что многие курсы по информатике говорят о большой длине и деталях ... Я надеюсь на короткое замыкание, посмотрев на какой-то курс крушения или самородки.)
• Каковы некоторые хорошие примеры таких протоколов, которые Я мог бы моделировать или даже использовать из коробки? (Я упоминаю Dropbox и IMAP выше ... Я, вероятно, следует читать IMAP RFC.)

Answer 1

Пара мыслей:

1). Какие предположения вы можете сделать о надежности доставки уведомлений об изменениях? И надежность заказа этих уведомлений? Мой инстинкт заключается в том, что лучше терпеть потерю и неправильный порядок, возвращаясь к просьбе о полной перепродаже метаданных.

2). Фактически у вас есть поток метаданных, а также поток данных. Какие предположения вы можете сделать относительно их относительного упорядочения. Можете ли вы получить новые данные с версией до получения метаданных? Повторяю, я подозреваю, что это может произойти.Я ожидаю, что полезная нагрузка данных должна содержать информацию о версии метаданных. Следовательно, клиенты могут обновлять свои метаданные, когда им это нужно?

3). Возможно ли, чтобы данные, соответствующие двум различным версиям метаданных, поступали на устройство. Я подозреваю «да». Как легко клиент может справиться с этим?

4). Метаданные, возможно, должны включать информацию представления или проверки.

Answer 2

Метаданные, которые вы описали, представляют собой график. Однако переход на OWL/RDF-трек может быть довольно сменой. В принципе, вам просто нужно иметь свойства объектов, которые могут быть взаимосвязаны (например, файлы, выровненные по иерархии). С этой точки зрения JSON - очень естественный выбор для доступа к свойствам, в сочетании с REST API. Если этот подход выбран, я рекомендую сначала изучить Open Data Protocol.

Кстати, почему бы просто не использовать систему контроля версий, например. Git, и имеют ли свойства как объекты JSON внутри текстовых файлов в системе? Если каждый объект имеет свои метаданные, хранящиеся в очень маленьком фрагменте JSON в отдельном файле, система автоматически сможет выполнять большинство обновлений и автоматически разрешать конфликты. Большинство систем контроля версий обеспечивают хороший APIS для этого типа целей.

Answer 3

Если бы я хотел сделать это быстро, не слишком много времени разработки, я бы просто использовал WebDAV для файлов метаданных и выполнял их. ИМО, которая должна охватывать большинство ваших требований. Кроме того, использование существующего протокола имеет преимущества перед пользовательскими протоколами в существующих библиотеках, не тратя время на разработку кода реализации кода и кода отладки.

EDIT: Если вы сделаете файл конфигурации простым слиянием в виде файла, вам просто нужно сохранить 2 версии конфигурационного файла. Одна базовая версия, как конфигурация выглядела в прошлый раз, когда мы синхронизировались. Одна текущая версия метаданных, а затем вы получаете версию метаданных вашего сверстника. С этими 3 файлами вы делаете простое слияние 3-way, вы автоматически определяете конфликты для более новой версии, и это все. Сохранение базовой версии важно. Теперь, если вы слились с несколькими клиентами, вы можете объединиться в разных точках и, следовательно, в качестве базы данных потребуется другая версия вашего конфигурационного файла. Просто сохраняйте каждый результат синхронизации, пока вы не перезапишете его новой синхронизацией от этого однорангового клиента. Теоретически вы можете иметь файлы конфигурации XML, но трехстороннее слияние XML-файлов просто болезненно, а инструменты еще не совсем там, imho. Конкретный формат или тип приложения не имеет большого значения.

Answer 4

Посмотрите на этом протоколе спецификации заявки

SLEEP - SYNCABLE LIGHTWEIGHT EVENT EMITTING PERSISTENCE