Come progettare un protocollo applicativo di alto livello e il formato dei dati per la sincronizzazione dei metadati tra dispositivi e server?

Question

Sto cercando indicazioni su come pensare meglio sulla progettazione di un protocollo applicativo di alto livello per sincronizzare i metadati tra i dispositivi dell'utente finale e un server.

Il mio obiettivo: l'utente può interagire con i dati dell'applicazione su qualsiasi dispositivo o sul web. Lo scopo di questo protocollo è comunicare le modifiche apportate su un endpoint ad altri endpoint tramite il server e garantire che tutti i dispositivi mantengano un'immagine coerente dei dati dell'applicazione. Se l'utente apporta modifiche su un dispositivo o sul web, il protocollo invierà i dati al repository centrale, da dove altri dispositivi possono estrarlo.

Alcuni altri pensieri progettuali:

• mi chiamano "metadati la sincronizzazione", perché i carichi saranno abbastanza piccola, sotto forma di ID oggetto e piccoli metadati relativi a tali ID. Quando gli endpoint client recuperano nuovi metadati su questo protocollo, recuperano i dati degli oggetti effettivi da un'origine esterna basata su questi metadati. Recuperare i dati dell'oggetto "reale" è fuori dall'ambito, sto solo parlando di sincronizzazione dei metadati qui.
• Utilizzo di HTTP per il trasporto e JSON per contenitore del carico utile. La domanda è fondamentalmente su come progettare al meglio lo schema del payload JSON.
• Voglio che questo sia facile da implementare e mantenere sul web e su desktop e dispositivi mobili. L'approccio migliore sembra essere una semplice richiesta/risposta HTTP basata su timer o evento senza alcun canale persistente. Inoltre, non dovresti avere un dottorato per leggerlo, e voglio che le mie specifiche si adattino su 2 pagine, non 200.
• L'autenticazione e la sicurezza sono fuori dallo scopo di questa domanda: supponiamo che le richieste siano sicure e autenticate.
• L'obiettivo è la coerenza finale dei dati sui dispositivi, non è interamente in tempo reale. Ad esempio, l'utente può apportare modifiche su un dispositivo mentre è offline. Quando si ritorna in linea, l'utente eseguirà un'operazione di "sincronizzazione" per inviare modifiche locali e recuperare le modifiche remote.
• Detto questo, il protocollo dovrebbe sostenere entrambe queste modalità di funzionamento:
  • Partendo da zero su un dispositivo, dovrebbe essere in grado di tirare l'intero quadro dei metadati
  • "sync as you go". Quando si guardano i dati su due dispositivi affiancati e si apportano modifiche, è opportuno spingere facilmente tali modifiche come brevi messaggi individuali che l'altro dispositivo può ricevere quasi in tempo reale (a condizione che decida di contattare il server per la sincronizzazione).

Come esempio concreto, si può pensare di Dropbox (non è quello a cui sto lavorando, ma aiuta a capire il modello): su una gamma di dispositivi, l'utente può gestire un file e cartelle: spostali, creane di nuovi, rimuovi quelli vecchi ecc. E nel mio contesto i "metadati" sarebbero la struttura di file e cartelle, ma non i contenuti effettivi dei file. E i campi dei metadati sarebbero qualcosa come nome file/cartella e ora di modifica (tutti i dispositivi dovrebbero vedere lo stesso tempo di modifica).

Un altro esempio è IMAP. Non ho letto il protocollo, ma i miei obiettivi (meno i corpi dei messaggi effettivi) sono gli stessi.

Percepita ci sono due grandi approcci come questo è fatto:

• messaggi transazionali. Ogni cambiamento nel sistema viene espresso come delta e gli endpoint comunicano con tali delta.Esempio: changeset DVCS.
• REST: comunicare il grafico dell'oggetto nel suo complesso o in parte, senza preoccuparsi tanto delle singole modifiche atomiche.

EDIT: alcune delle risposte, giustamente dicono che non c'è abbastanza informazioni circa l'applicazione di offrire buoni suggerimenti abbastanza. La natura esatta dell'app potrebbe essere fonte di distrazione, ma un'app per la lettura di RSS molto semplice è un'approssimazione abbastanza buona. Quindi supponiamo che le specifiche dell'app siano le seguenti:

• Esistono due classi: feed e voci.
• Posso aggiungere, rinominare ed eliminare i feed. L'aggiunta di un feed si iscrive ad esso e inizia a ricevere elementi per quel feed. Posso anche riordinare l'ordine di visualizzazione dei feed nell'interfaccia utente.
• Mentre leggo gli elementi, sono contrassegnati come letti. Non posso contrassegnarli non letti o fare qualsiasi altra cosa con loro.
• Sulla base di quanto sopra, il modello a oggetti è:
  • "nutrire" ha gli attributi "url", "displayName" e "displayorder" (displayorder è indice del mangime nella lista dei feed di UI; riordino alimenta cambia a livello locale displayOrder di tutti i feed in modo che gli indici rimangano unici e sequenziali).
  • "articolo" ha attributi "url" e "non letti" e relazione "feed" (ciascun elemento appartiene a un feed). "url" si comporta anche come GUID per l'elemento.
  • il contenuto dell'elemento reale viene scaricato localmente su ciascun dispositivo e non fa parte della sincronizzazione.

Sulla base di questo progetto, posso impostare il mio app su un dispositivo: aggiungere un po 'di feed, rinominare e riordinare loro, e leggere alcuni articoli su di loro, che vengono poi contrassegnati come non letti. Quando cambio i dispositivi, l'altro dispositivo può sincronizzare la configurazione e mostrarmi la stessa lista di feed con gli stessi nomi, ordine e gli stessi stati letti/non letti.

(fine edit)

Quello che vorrei nelle risposte:

• C'è qualcosa di importante ho lasciato sopra? Vincoli, obiettivi?
• Qual è una buona lettura di sottofondo su questo? (Mi rendo conto che questo è ciò di cui molti corsi di informatica parlano a lungo e in dettaglio ... spero di mandarlo in cortocircuito osservando alcuni corsi o pepite.)
• Quali sono alcuni buoni esempi di tali protocolli che Potrei modellare dopo, o anche usare fuori dalla scatola? (Cito Dropbox e IMAP sopra ... forse dovrei leggere la RFC IMAP.)

Answer 1

Un paio di pensieri:

1). Quali sono le tue supposizioni sull'affidabilità della consegna delle notifiche di modifica? E l'affidabilità dell'ordine di quelle notifiche? Il mio istinto è che è meglio tollerare la perdita e l'ordine errato tornando a richiedere la completa riconsegna dei meta-dati.

2). In effetti hai un flusso di meta-dati e anche un flusso di dati. Quali ipotesi puoi fare riguardo al loro ordine relativo. Puoi ricevere dati con nuove versioni prima che arrivino i meta dati? Indovinando di nuovo, sospetto che ciò possa accadere.Mi aspetto che i payload dei dati debbano contenere informazioni sulla versione dei metadati. Quindi i clienti possono aggiornare i loro meta-dati quando ne hanno bisogno?

3). È possibile che i dati corrispondenti a due versioni differenti dei meta-dati arrivino al dispositivo. Sospetto "si". Come può un cliente affrontare facilmente questo?

4). I meta-dati potrebbero dover includere informazioni di presentazione o di convalida.

Answer 2

I metadati che hai descritto suona grafico. Tuttavia, il passaggio alla traccia OWL/RDF potrebbe essere un bel cambiamento. Fondamentalmente, è sufficiente disporre di proprietà sugli oggetti che possono essere interconnessi (ad esempio file allineati in gerarchia). Da questo punto di vista JSON è una scelta molto naturale per l'accesso alle proprietà, se combinato con l'API REST. Se scegli questo approccio, ti consiglio di studiare prima lo Open Data Protocol.

A proposito, perché non usare solo il sistema di controllo della versione, ad es. Git e le proprietà come oggetti JSON all'interno di file di testo nel sistema? Se ciascun oggetto ha i suoi metadati memorizzati in un piccolo blocco JSON in un file separato, il sistema sarà automaticamente in grado di eseguire la maggior parte degli aggiornamenti e la risoluzione automatica dei conflitti. La maggior parte dei sistemi di controllo delle versioni fornisce un buon APIS per questo tipo di scopo.

Answer 3

Se volessi farlo rapidamente senza troppo tempo di sviluppo, userei semplicemente WebDAV su file di metadati e sarò fatto. IMO, che dovrebbe coprire la maggior parte delle tue esigenze. Anche l'utilizzo del protocollo esistente presenta vantaggi rispetto ai protocolli personalizzati nelle librerie esistenti e non trascorre molto tempo a reinventare il codice di implementazione del protocollo "ruota e debugging".

MODIFICA: Se si semplifica l'unione del file di configurazione come file, è sufficiente mantenere 2 versioni del file di configurazione. Una versione di base, come appariva la configurazione l'ultima volta che ci siamo sincronizzati. Una versione corrente dei metadati e quindi ottieni la versione dei metadati del tuo pari. Con questi 3 file fai una semplice unione a 3 vie, decidi automaticamente i conflitti per la versione più recente e basta. Mantenere la versione di base è importante. Ora, se ti unisci a più client, puoi unire in punti diversi e quindi richiedere una versione diversa del tuo file di configurazione come base. Tieni semplicemente ogni risultato di una sincronizzazione, finché non lo sovrascrivi con una nuova sincronizzazione da quel client peer. In teoria puoi avere file di configurazione XML, ma la fusione a 3 vie di file XML è solo dolorosa e gli strumenti non sono ancora lì, imho. Il formato specifico o il tipo di app non ha molta importanza.

Answer 4

Date un'occhiata a questa specifica proposta di protocollo

SLEEP - SYNCABLE LIGHTWEIGHT EVENT EMITTING PERSISTENCE