Google Drive

Se stai provando a creare la tua versione di google doc, ti suggerisco di dare un'occhiata all'API di Google Realtime . Google lo ha rilasciato di recente con l'intento di consentire ad altri sviluppatori di utilizzare gli stessi strumenti che hanno utilizzato per consentire la collaborazione in tempo reale. Ciò ti consentirebbe di risparmiare tempo sul tuo sviluppo e ottenere un prodotto funzionante prima.

Potresti facilmente prendere i dati presenti nel documento e inserirli nel tuo database a intervalli regolari, oppure far sì che il database stesso sia un "partecipante" dello scambio, semplicemente ascoltando e registrando tutte le modifiche. Consente inoltre a un utente di definire le proprie strutture di dati che sono quindi utilizzabili nell'API realtime, quindi sei libero di estenderlo come meglio credi.

Unità non Google

Pertanto, secondo la tua ricerca, Google Drive non è un'opzione. Va bene, ma sarà più difficile e forse non funzionerà altrettanto bene, a seconda di quanto ci hai messo dentro.

Ecco una strategia generale che io utilizzerei per risolvere questo problema:

1. Il server deve essere il multiplexer di comunicazione. Ogni persona parla al server e il server invia tali informazioni a tutti gli altri. In questo modo il server ha sempre la vista più aggiornata del documento.

2. Trova un algoritmo / modulo di terze parti per la risoluzione dei conflitti. La risoluzione dei conflitti è dura, ed è qualcosa che non è ancora perfetto. Fare questo da solo potrebbe facilmente aumentare la portata del progetto per essere troppo grande. Se non è possibile utilizzare un algoritmo di terze parti, suggerirei di consentire solo a un utente di modificare un'area di un tempo, in modo che l'utente debba ottenere un blocco prima di modificare un'area, o si rischia di distruggere un altro utente, diventerà molto vecchio, molto veloce.

3. Quando un nuovo utente si unisce, dai loro il documento più recente e avvia automaticamente lo streaming dei comandi a loro. Il server ha la vista più recente e quindi può distribuirlo automaticamente.

4. Effettua il backup nel database a determinati intervalli. Decidi quante volte vuoi eseguire il backup (ogni 5 minuti o forse ogni 50 modifiche). Ciò ti consente di mantenere il backup che desideri.

Problemi: Questa non è una soluzione perfetta, quindi ecco alcuni problemi che potresti incontrare.

1. La velocità del server potrebbe rallentare le prestazioni

2. Troppe persone che leggono / scrivono potrebbero sovraccaricare il server

3. Le persone potrebbero non essere sincronizzate in caso di smarrimento di un messaggio, pertanto ti consigliamo di assicurarti di sincronizzarti in punti regolari. Ciò significa inviare di nuovo l'intero messaggio, che può essere costoso, ma altrimenti le persone potrebbero non avere lo stesso documento e non saperlo.

Consiglierei 1 copia persistente del documento sul server. Quando un client si connette al server, si invia un comando UPDATE a quel client con tutte le modifiche.

Aggiorna flusso di lavoro

L'utente causa l'attivazione della modifica - > Il cliente invia UPDATE a Server - > Il server invia UPDATE ai client

Trigger possibili

1. L'utente fa clic su Salva
2. L'utente completa un'attività specifica
   • Termina la modifica di una cella
   • Termina la modifica di una frase / paragrafo / linea
3. L'utente fa clic su Annulla
4. L'utente preme il tasto Invio
5. L'utente digita una chiave (salva ogni modifica)

Implementazione aggiornamento

Suggerirei di poter ricreare il documento con una serie di comandi UPDATE in modo che il server memorizzi ogni UPDATE e quando un nuovo client si connette al client può essere inviata la serie di aggiornamenti e da sola può crea il documento da visualizzare all'utente. Inoltre, potresti avere in alternativa un comando SAVE che è separato e avere UPDATE essere modifiche temporanee che possono essere utilizzate per% richieste diUNDO e avere SAVE effettivamente memorizzarle per riaprirle se il server è chiuso o tutti i client si disconnettono.

1) Dai un'occhiata a Knockout.js

Segue un pattern MVVM e invierà automaticamente notifiche alla vista in base alle modifiche apportate al modello. Ad esempio, guarda nella array osservabile per fornire ulteriori informazioni su come farlo.

2) Mescolalo con SignalR e ora dovresti avere la possibilità di inviare notifiche ad altri utenti che lavorano al documento. Dal loro sito:

SignalR also provides a very simple, high-level API for doing server to client RPC (call JavaScript functions in your clients' browsers from server-side .NET code) in your ASP.NET application, as well as adding useful hooks for connection management, e.g. connect/disconnect events, grouping connections, authorization.

Quindi avrai bisogno di avere alcuni hook a livello di modello all'interno di Knockout.js per effettuare alcune chiamate SignalR ogni volta che si verifica una modifica. Gli altri client riceveranno l'avviso da SignalR e quindi attiveranno una modifica corrispondente nella loro copia del modello, che tornerà alla loro vista.

È una combinazione interessante dei due framework e dovresti essere in grado di cercare e raccogliere più informazioni per gestire i particolari.

Ad esempio, questo esempio di codeproject indirizza in modo specifico Co Working UIs and Continuous Clients che sembra essere esattamente quello che stai cercando di fare.

New age web applications may need to offer new age user experiences - and should handle co-working and continuous client scenarios properly. This involves ensuring that the user interface is syncing properly itself across devices and across users to ensure the state of the application and user interface is maintained "as is".

Questo post di blog sembra essere un punto di ingresso in una serie di post di blog che discutono l'uso dei due pacchetti e contrasta quello con un approccio tradizionale ASP.NET. Può fornire alcuni punti da tenere in considerazione mentre stai progettando il tuo sito.

Questo post di blog sembra essere un po 'più basilare e fornisce il fondamento per combinare i due pacchetti.

Divulgazione: Non sono affiliato con nessuno dei collegamenti sopra riportati, né ho davvero scavato nei loro contenuti per vedere quanto è corretto o corretto.

La soluzione è Operational Transformation (OT). Se non ne hai sentito parlare, OT è una classe di algoritmi che eseguono la concorrenza in tempo reale su più siti. OT è come un git in tempo reale. Funziona con qualsiasi quantità di lag (da zero a una vacanza estesa). Permette agli utenti di apportare modifiche live e simultanee con bassa larghezza di banda. OT ti offre la coerenza finale tra più utenti senza tentativi, senza errori e senza che nessun dato venga sovrascritto.

Ma implementare OT è un compito difficile e richiede tempo. Quindi potresti voler utilizzare una libreria esterna come link .

Dipende principalmente dal tipo di documenti e dal modo in cui i tuoi utenti collaborano.

Tuttavia, vorrei:

1. consente a tutti i client di inviare modifiche non salvate al server ogni tanto (dipende da come gli utenti lavorano con i documenti).
2. il server memorizza i delta nella sessione dell'utente (anche per un fat client hai bisogno di qualcosa come una sessione)
3. altri client che modificano / visualizzano lo stesso documento ricevono quelle modifiche temporanee o almeno un suggerimento che potrebbe esserci.

I vantaggi:

• nessun aggiornamento DB a meno che qualcuno non faccia clic su "Salva"
• backup per il caso in cui il client si blocca (per il periodo di sessione)
• il tuo server decide come e quali dati inoltrare a quale client (ad es. puoi avviare la funzione con una nota e successivamente implementare un'unione ed evidenziatura più sofisticata)

Svantaggi:

• non "tempo reale" - ad es. invii ogni 30 secondi, ma qualcuno digita 3 frasi in quel momento.
• più traffico di rete, a seconda dei documenti e della collaborazione
• eventualmente sessioni di grandi dimensioni
• probabilmente un alto sforzo di calcolo se molti utenti collaborano e fanno molte modifiche

In sostanza, ciò che stai chiedendo è come gestire lo stato mutabile condiviso. Salvare è la parte facile; ma come gestisci più persone che modificano la stessa cosa allo stesso tempo? Vuoi che tutti gli utenti visualizzino lo stesso documento mentre sincronizzi le modifiche simultanee, tutto in tempo reale.

Come avrai probabilmente capito, è un problema difficile! Esistono alcune soluzioni pragmatiche:

1. Modifica i requisiti dell'applicazione per non consentire l'editing simultaneo vero. Le modifiche possono essere unite con i sistemi di controllo del codice sorgente, con i risultati trasmessi a ciascun cliente. Potresti crearlo da solo, ma sarebbe un'esperienza utente peggiore.
2. Esternalizza la sincronizzazione delle mutazioni di stato con una soluzione open-source che si integra con la tua tecnologia esistente. ShareDB è l'attuale leader in questo spazio. Si basa sulla trasformazione operativa e viene utilizzato in almeno un sistema di produzione. Questo si occuperà del problema di risparmio che ti riguarda, ma non aiuterà con nessuna delle funzionalità UX aggiuntive obbligatorio per qualsiasi applicazione collaborativa.
3. Utilizza una piattaforma disponibile come Convergence (disclaimer: I am a founder) per gestire tutti i bit difficili per te. Avrai anche strumenti aggiuntivi per la collaborazione in tempo reale come il tracciamento di cursore / mouse, selezioni e chat per costruire rapidamente un'esperienza di collaborazione superiore. Vedi questa domanda per un buona raccolta di tutti gli strumenti esistenti là fuori.