DE202010018490U1

DE202010018490U1 - Architektonisches Muster für persistenten Webanwendungsentwurf

Info

Publication number: DE202010018490U1
Application number: DE202010018490.8U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2009-04-03
Filing date: 2010-04-01
Publication date: 2017-02-09
Anticipated expiration: 2020-04-02
Also published as: AU2010232614A1; EP2665001B1; US20100257230A1; CN102449628A; KR20120005490A; EP2665001A3; EP2414965A1; US8725793B2; WO2010114964A1; EP2665001A2; AU2010232614B2; CA2760798A1; KR101647071B1

Abstract

Serversystem, Folgendes umfassend: einen Prozessor oder mehrere Prozessoren; Speicher; und ein oder mehrere Programme, worin ein oder mehrere Programme im Speicher für die Ausführung von einem oder mehreren Prozessoren gespeichert sind. Das bzw. die Programme beinhalten Anweisungen für Folgendes: das Empfangen einer ersten Anfrage für ein Datenelement von einem Clientgerät, worin die erste Anfrage einen Identifier des Datenelements beinhaltet; als Antwort auf die erste Anfrage: das Berechnen einer ersten Prüfsumme des Datenelements; und das Senden des Datenelements und der ersten Prüfsumme an das Clientgerät, für das Speichern in einer lokalen Datenbank am Clientgerät, sodass das Clientgerät keine Prüfsumme des Datenelements berechnet; das Empfangen einer zweiten Anfrage für das Datenelement vom Clientgerät, worin die zweite Anfrage den Identifier des Datenelements und die erste Prüfsumme, die zuvor vom Serversystem berechnet wurde, beinhaltet; als Antwort auf die zweite Anfrage: das Berechnen einer zweiten Prüfsumme des Datenelements und das Vergleichen der ersten Prüfsumme mit der zweiten Prüfsumme; das Bestimmen, dass das Datenelement basierend auf mindestens teilweise dem Vergleich der ersten mit der zweiten Prüfsumme aktualisiert wurde; gemäß der Bestimmung, dass das Datenelement aktualisiert wurde: das Senden einer Antwort an das Clientgerät, in der angegeben wird, dass das Datenelement aktualisiert wurde, die Antwort einschließlich einer Anfrage für eine erste Vielzahl an Nachrichten-Identifiern, die jeweils zu einer Komponente des Datenelements, das in der lokalen Datenbank gespeichert ist, gehören; das Empfangen einer Kommunikation vom Clientgerät, worin die Kommunikation die erste Vielzahl der Nachrichten-Identifier umfasst; als Antwort auf die zweite Anfrage: Vergleichen der ersten Gruppe von Nachrichten-Identifiern, die vom Clientgerät empfangen wurden, mit einer zweiten Vielzahl von Nachrichten-Identifiern, die mit einer zweiten Gruppe von Komponenten des Datenelements verbunden sind; das Bestimmen eines entsprechenden Nachrichten-Identifiers in der zweiten Vielzahl der Nachrichten-Identifier, der nicht in der ersten Vielzahl von Nachrichten-Identifiern vorhanden ist: und als Antwort auf das Bestimmen des entsprechenden Nachrichten-Identifiers: das Senden der entsprechenden Komponente, die mit dem entsprechenden Identifier verbunden ist, und der zweiten Prüfsumme an das Clientgerät.

Description

TECHNISCHES GEBIET
Die offenbarten Ausführungsformen beziehen sich im Allgemeinen auf das Gebiet der Client-Server-Computernetzwerksysteme und im Besonderen auf Systeme und Verfahren für die Entwicklung von Webanwendungen mit Offline-Fähigkeiten. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
HINTERGRUND
Webanwendungen (z. B. Anwendungen, auf die hauptsächlich über einen Webbrowser zugegriffen wird und die Daten von einem Remote-Server empfangen) werden immer beliebter. Webanwendungen werden für viele verschiedene Zwecke verwendet, einschließlich E-Mail-, Kalender-, Bank-, Textverarbeitungs- und Bildbearbeitungsanwendungen. Durch die weitverbreitete Nutzung sind jedoch zahlreiche Probleme entstanden. Beispielsweise kommt es häufig zu einer Verzögerung zwischen dem Senden einer Anfrage über ein Netzwerk und das Empfangen einer Antwort, auch Netzwerklatenz genannt. Diese Netzwerklatenz verringert die Reaktionsfähigkeit von Webanwendungen, da sie auf Daten von einem Remote-Server warten müssen, bevor sie auf die Anfragen antworten und so von einem Benutzer angegebene Operationen durchführen können. Diese zusätzliche Wartezeit kann für den Benutzer sehr frustrierend sein. Wenn eine Netzwerkverbindung nicht verfügbar ist, kann die Webanwendung zudem keine Daten vom Remote-Server empfangen, wodurch die Funktionalität der Webanwendung begrenzt ist. Ähnlich frustrierend kann es für einen Benutzer sein, wenn eine Anwendung aufgrund einer fehlenden Netzwerkverbindung nicht verwendet werden kann.
ZUSAMMENFASSUNG
Entsprechend verringern oder beseitigen das hier offenbarte Verfahren und System die oben beschriebenen Probleme, indem lokale Datenstrukturen für das Speichern von Datenelementen bereitgestellt werden, die von der Webanwendung verwendet werden sollen. Mithilfe des offenbarten Verfahrens und Systems werden die negativen Auswirkungen der Netzwerklatenz und einer fehlenden Netzwerkverbindung auf das Benutzererlebnis verringert. In einigen Ausführungsformen werden die in der lokalen Datenbank gespeicherten Datenelemente von der Webanwendung in einem Offline-Modus verwendet. In diesen Ausführungsformen verwendet die Webanwendung die lokal gespeicherten Datenelemente, um zumindest einige der Funktionen bereitzustellen, die üblicherweise von der Webanwendung bereitgestellt werden, wenn eine Netzwerkverbindung besteht (z. B. das Anzeigen von E-Mails). In einigen Ausführungsformen werden die in der lokalen Datenbank gespeicherten Datenelemente von der Webanwendung in einem Online-Modus verwendet, um die Reaktionsfähigkeit der Webanwendungen auf Benutzeranfragen zum Durchführen von Operationen (z. B. Anzeigeoperationen) auf den Datenelementen zu verbessern. Bei E-Mail-Nachrichten, die in der lokalen Datenbank zwischengespeichert sind, können diese E-Mail-Nachrichten beispielsweise sofort angezeigt werden, wenn der Benutzer eine der zwischengespeicherten Nachrichten anzeigen möchte, ohne dass auf eine Antwort von einem Remote-Server auf die Anfrage gewartet werden muss.
Gemäß eines ersten Aspekts der vorliegenden Erfindung verfügt ein Clientgerät über einen Computerprozessor und einen Computerspeicher, einen Webbrowser, der zur Ausführung auf dem Clientgerät konfiguriert ist, eine lokale Webanwendung, die im Webbrowser operieren kann, eine Webschnittstelle, die Kommunikationen zwischen der lokalen Webanwendung und einem zugehörigen Serversystem verwalten kann, eine Warteschlange für Schreibanfragen, die im Speicher gepflegt wird, und eine persistente lokale Datenbank, die im Speicher gepflegt wird und eine Vielzahl an Datenelementen beinhaltet, wobei jedes einem Identifier zugeordnet ist, der dafür sorgt, dass das jeweilige Datenelement eindeutig auf dem Clientgerät und dem Serversystem identifiziert wird. Wenn eine Webanwendung auf dem Clientgerät eine Operation auf einem Datenelement durchführen muss, gibt die Webanwendung eine Datenbankanfrage aus, um festzustellen, ob sich ein Datenelement in der lokalen Datenbank befindet. Ist dies nicht der Fall, gibt die Webanwendung die Datenanfrage über die Webschnittstelle an den Systemserver aus. Wenn sich das Datenelement nicht in der lokalen Datenbank befindet und die Operation eine Aktualisierung des Datenelements umfasst, führt die Webanwendung die Operation auf den in der Datenbank gespeicherten Datenelementen durch und schreibt Informationen, die die Operation kennzeichnen, zusammen mit dem Identifier des Datenelements in die Warteschlange für Schreibanfragen. Wenn eine Netzwerkverbindung zwischen dem Clientgerät und dem Serversystem vorhanden ist, leert die Webschnittstelle die Warteschlange für Schreibanfragen in das Serversystem, welches anhand dieser Informationen die Einträge in seiner Datenbank aktualisiert, die durch die Clientoperationen geändert wurden. Dies ist ein Beispiel für einen Write-Through-Cache. Bei einer Ausführungsform der vorliegenden Erfindung wird auch eine LRU (Least Recently Used)-Cache-Ersetzungsrichtlinie implementiert, bei der Speicherplatz für einen neuen Eintrag in der lokalen Datenbank freigegeben wird, indem der am längsten unbenutzte Eintrag gelöscht wird.
Bei einigen Ausführungsformen wird dieses Software-Caching als Hardware-Caching analogisiert. Indem Hardware-Caching-Strategien in Software-Caching-Strategien analogisiert werden, kann die Leistung von Webanwendungen, die Software-Caching verwenden, verbessert werden, indem Techniken verwendet werden, die vergleichbar sind mit denen, die zur Leistungsverbesserung des Hardware-Caching verwendet werden. Diese Caching-Techniken sind häufig weithin bekannt und gründlich getestet. Die Geschwindigkeit des Cache-Zugriffs kann beispielsweise verbessert werden, indem ein Highspeed-L1-Cache zwischen einem Prozessor (CPU) und einem größeren, jedoch langsameren L2-Cache eingesetzt wird. In ähnlicher Weise kann die Zugriffsgeschwindigkeit auf Datenelemente für eine Webanwendung verbessert werden, indem eine In-Memory-Datenbank zwischen der Webanwendung und der persistenten Datenbank eingesetzt wird. Bei anderen Ausführungsformen kann das Dokumentobjektmodell des Webbrowsers als L1-Cache verwendet werden. Wie von den in Hardware vorhandenen Cache-Typen vorgeschlagen, kann Software mit einem als L1-Cache verwendeten Dokumentobjektmodell vom Typ „Write-Back” oder „Write-Through” sein. Es wäre angemessen, einen Write-Back-Cache der Dokumentobjektmodell-Fragmente als L1-Cache zu verwenden, wenn die Webanwendung einige Benutzeraktionen durch direktes Modifizieren des Dokumentobjektmodells implementiert haben. Zu den anderen Funktionen in der Ausführungsform, die durch diese Analogie mit Hardware-Caching vorgeschlagen werden, gehören das Prefetching von Datenelementen und das Load Forwarding.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockdiagramm, das die Infrastruktur eines verteilten Client-Server-Systems gemäß einigen Ausführungsformen darstellt.
2 ist ein Blockdiagramm, das die Struktur eines exemplarischen Clientgeräts gemäß einigen Ausführungsformen darstellt.
3 ist ein Blockdiagramm, das die Struktur eines exemplarischen Serversystems gemäß einigen Ausführungsformen darstellt.
4 ist ein Blockdiagramm, das den Zusammenhang zwischen Komponenten des verteilten Client-Server-Systems gemäß einigen Ausführungsformen darstellt.
5A–5C sind Blockdiagramme, die den Startvorgang einer Multi-Thread-Softwareanwendung in einem verteilten Client-Server-Systems gemäß einigen Ausführungsformen darstellen.
6A ist ein Blockdiagramm, das Datenstrukturen in einem Serversystem, das mit der Webanwendung verbunden ist, gemäß einigen Ausführungsformen darstellt.
6B ist ein Blockdiagramm, das Datenstrukturen in einem Clientgerät, das mit einer persistenten Webanwendung verbunden ist, gemäß einigen Ausführungsformen darstellt.
7A–7B beinhalten ein Flussdiagramm, das die Client- und Serverrollen in einem Prozess für das Übertragen von Daten zwischen einer persistenten Webanwendung auf einem Clientgerät und einem Serversystem gemäß einigen Ausführungsformen darstellt.
8A–8C beinhalten ein Flussdiagramm, das die Client- und Serverrollen in einem Prozess für die Synchronisierung von Daten zwischen Datenbank mithilfe eines Prüfsummenaustauschs gemäß einigen Ausführungsformen darstellt.
Gleiche Referenzziffern beziehen sich in allen Zeichnungen auf die dazugehörigen Teile.
BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
1 ist ein Blockdiagramm, das die Infrastruktur eines verteilten Client-Server-Systems gemäß einigen Ausführungsformen darstellt. Das verteilte System umfasst mehrere Clientgeräte 102 und mehrere Serversysteme 106. Diese Komponenten sind über mindestens ein Kommunikationsnetzwerk 104 verknüpft (z. B. über das Internet, andere Wide Area Networks, Local Area Networks usw.), sodass die verschiedenen Komponenten miteinander kommunizieren können. In einigen Ausführungsformen sind die jeweiligen Serversysteme 106 ein einzelner Server. In anderen Ausführungsformen umfasst ein Serversystem 106 mehrere Server, wie eine Webschnittstelle (Front-End-Server) 108, eine oder mehrere Serveranwendungen 110 (die auf einem oder mehreren Servern implementiert werden können) und eine oder mehrere zentrale Datenbanken 120, die über ein LAN (Local Area Network) miteinander verbunden sind und Informationen mit den Clientgeräten 102 über eine gemeinsame Schnittstelle austauschen (z. B. ein oder mehrere Serversysteme, auch Front-End-Server genannt). In Ausführungen mit einer Vielzahl von Serversystemen 106 können die Serversysteme 106 über ein LAN (Local Area Network) oder ein anderes Kommunikationsnetzwerk verbunden werden.
Ein Clientgerät 102 umfasst eine Clientanwendung, wie einen Webbrowser 112. Ein Benutzer kann den Webbrowser 112 verwenden, um auf eine oder mehrere Webanwendungen 114 der Serversysteme 106 zuzugreifen. Der Webbrowser 112 und die Webanwendung 114 innerhalb des Webbrowsers 112 haben Zugriff auf Datenelemente, die in einer lokalen Datenbank 116 auf dem Client 102 gespeichert sind. In einigen Ausführungsformen müssen für den Zugriff auf eine Webanwendung 114 ein Programm von einem Serversystem 106 heruntergeladen und Daten in einer lokalen Datenbank 116 zur Verwendung durch die Webanwendung 114 gespeichert werden. Das Clientgerät 102 (manchmal „Clientgerät” oder „Clientcomputer” genannt) kann jeder Computer oder ein ähnliches Gerät sein, der bzw. das Daten vom Serversystem 106 empfangen und Anfragen (z. B. Webanwendungs-Datenanfragen, Suchanfragen, Informationsanfragen, Anmeldeanfragen usw.) an dieses senden kann. Zu den Beispielen für Clientgeräte (ohne Einschränkungen) gehören Desktopcomputer, Notebooks, Tablets, Mobilgeräte, wie Mobiltelefone und PDAs (Personal Digital Assistants), und Set-Top-Boxen. In der vorhandenen Anwendung steht der Begriff „Webanwendung” praktisch für jede interaktive Anwendung, die dem Benutzer Zugriff auf Inhalte bietet, die von einem Serversystem 106 empfangen wurden. Anfragen von einem Clientgerät 102 werden mithilfe des HTTP-Protokolls an ein entsprechendes Serversystem 106 übertragen, wobei HTTP-Anfragen über eine Kommunikationsschnittstelle 118 oder ähnliche Netzwerk-Kommunikationsprotokolle verwendet werden.
Ein Serversystem 106 umfasst mindestens eine Webschnittstelle (Front-End-Server) 108, eine Serveranwendung 110 und eine zentrale Datenbank 120. Die Webschnittstelle 108 parst Anfragen von den Clientgeräten 102, ruft entsprechende Webanwendungen ab, die von der Serveranwendung 110 bereitstellt werden, und gibt die Webanwendungen an das/die anfragenden Clientgerät(e) 102 zurück. Je nach ihren entsprechenden Positionen in der Topologie des Client-Server-Systems ist die Webschnittstelle auf einem separaten („Front-End-Server”) 108 und die Serveranwendung auf einem separaten („Back-End-Server”) 110 implementiert. In der vorliegenden Anwendung werden die Begriffe „Webschnittstelle” und „Front-End-Server” synonym verwendet. In einigen anderen Ausführungsformen werden der Front-End-Server 108 und der Back-End-Server 110 zu einer Softwareanwendung oder zu einem Serversystem 106 zusammengeführt.
In einigen Ausführungsformen werden die Serversysteme 106 über mehrere Computer bereitgestellt (dargestellt durch N Anwendungsserver und N zentrale Datenbanken in 1), sodass mehrere Arten von Diensten, wie E-Mail-Dienste, Suchmaschinendienste, Kartendienste, Social Network-Dienste und dergleichen, bereitgestellt werden. In einigen anderen Ausführungsformen kann eine individuelle Dienstart auch auf mehrere Server verteilt werden. Beispiel: ein System, in dem eine Serveranwendung 110-1 ein webbasierter E-Mail-Dienst ist (z. B. die GMail-E-Mail-Anwendung). Datenelemente, wie E-Mail-Nachrichten, Konversationen (z. B. Listen mit E-Mail-Nachrichten), Thread-Listen (z. B. Konversationslisten) und Kontoinformatmonen (z. B. Benutzerprofile, Benutzervoreinstellungen und Kontoverlauf), können in einer oder mehreren zentralen Datenbanken 120 gespeichert werden, auf die die Serveranwendung 110 zugreifen kann. Serveranwendungen 110 können mit einer oder mehreren zentralen Datenbanken 120 verbunden werden. In einigen Ausführungsformen kann eine einzelne Serveranwendung 110 Zugriff auf eine einzelne zentrale Datenbank 120 haben (etwa wenn in der zentralen Datenbank gespeicherte Informationen nur von den einzelnen Serveranwendungen benötigt werden, während in anderen Ausführungsformen mehrere Serveranwendungen 110 Zugriff auf eine einzelne zentrale Datenbank 120 haben (etwa wenn eine kleine Informationsmenge von einer Reihe von Serveranwendungen 110 verwendet wird und diese Informationen häufig aktualisiert werden). In anderen Ausführungsformen können mehrere Serveranwendungen 110 mit mehreren zentralen Datenbanken 120 verbunden sein (etwa wenn eine große Datenmenge gespeichert ist und von einer großen Anzahl an Serveranwendungen 110 benötigt wird).
Die Aufmerksamkeit wird nun auf 2 gerichtet, die ein Blockdiagramm beinhaltet, das ein Computersystem (z. B. Clientgerät 102) gemäß einer Ausführungsform der vorliegenden Erfindung darstellt. Clientgerät 102 umfasst in der Regel eine oder mehrere Verarbeitungseinheiten (CPUs) 202, ein oder mehrere Netzwerke oder andere Kommunikationsschnittstellen 204, einen Speicher 212 und einen oder mehrere Kommunikationsbusse 214 zur Verbindung dieser Komponenten. Clientgerät 102 kann optional eine Benutzerschnittstelle 205 umfassen, die aus einem Anzeigegerät 206 und einer Tastatur/Maus 208 (oder in einigen Ausführungsformen aus einer berührungsempfindlichen Oberfläche 209) besteht. Speicher 212 umfasst einen Highspeed-RAM (Random Access Memory), wie einen DRAM, SRAM, DDR RAM oder andere Solid-State-Speichergeräte mit Direktzugriff, und kann auch einen nichtflüchtigen Speicher umfassen, wie ein oder mehrere Plattenspeicher, optische Speichergeräte, Flash-Speichergeräte oder andere nichtflüchtige Solid-State-Speichergeräte. Speicher 212 kann optional ein oder mehrere Speichergeräte beinhalten, das bzw. die remote von der/den CPU/s 202 angeordnet sind. Speicher 212 oder alternativ der/die permanente/n Speichergerät/e innerhalb des Speichers 212 bestehen aus einem computerlesbaren Datenspeicher. In einigen Ausführungsformen speichert der Speicher 212 oder das computerlesbare Speichermedium des Speichers 212 die folgenden Programme, Module und Datenstrukturen bzw. eine Teilmenge davon:

• ein Betriebssystem 216, das Verfahren zur Abwicklung von verschiedenen grundlegenden Systemdiensten und zur Ausführung von Aufgaben, die von der Hardware abhängen, umfasst;
• ein Kommunikationsmodul 218, das zum Verbinden des Clientgeräts 102 mit anderen Computern über eine oder mehrere Kommunikationsschnittstellen 204 (verdrahtet oder drahtlos) und ein oder mehrere Kommunikationsnetzwerke verwendet wird, wie das Internet, andere Wide Area Networks, Local Area Networks, Metropolitan Area Networks und so weiter;
• ein Webbrowser 112 für den Empfang einer Benutzeranfrage für eine Webanwendung 114, das Rendering der angefragten Webanwendung 114 auf dem Anzeigegerät 206 oder einem anderen Benutzeroberflächengerät, das ein Benutzeroberflächenmodul 228 verwendet, und das Speichern von Datenelementen in einer lokalen Datenbank 116. In einigen Ausführungsformen werden die Webanwendung 114, die lokale Datenbank 116 und das Benutzeroberflächenmodul innerhalb des Webbrowsers ausgeführt. – die Webanwendung/en 114 können einen Webanwendungsmanager 219 für die Koordination von Operationen in der Webanwendung 114, eine Warteschlange für Schreibanfragen 220 für das Rückstellen von Operationen aus dem Webanwendungsmanager 219, einen Aktions-Dispatcher 222 für das Schreiben in eine lokale Datenbank 116 und (optional) einen Prüfsummenrechner 224 für das Berechnen von Prüfsummen auf Datenelementen beinhalten; – die lokale Datenbank 116 speichert Datenelemente (z. B. 226-1. 226-2), die an der Webanwendung 114 von verschiedenen Serversystemen 106 empfangen wurden; – das Benutzeroberflächenmodul 228 beinhaltet ein Anzeigemodul 230 für das Rendern der Benutzeroberfläche und ein Controllermodul 232, um Benutzerinteraktionen zu erkennen und an andere Module weiterzugeben; und
• ein Response-Handler-Modul 234 für das Antworten auf Kommunikationen vom Systemserver, indem Datenelemente in der lokalen Datenbank 116 gespeichert und Informationen an die Webanwendung 114 kommuniziert werden.

Auch wenn 2 ein „Clientgerät 102” zeigt, ist das mit Bezug auf 2 beschriebene Clientgerät eher als funktionale Beschreibung der verschiedenen Funktionen, über die ein Clientgerät 102 verfügen kann, als strukturelles Schema der hier beschriebenen Ausführungsformen vorgesehen. In der Praxis und wie von Fachleuten anerkannt können Elemente, die separat angezeigt werden, kombiniert werden und umgekehrt. In einigen Ausführungsformen kann die Clientanwendung (z. B. der Webbrowser 112) beispielsweise in das Betriebssystem 216 integriert sein. In einigen Ausführungsformen können verschiedene Funktionen der Clientanwendung (z. B. Webbrowser 112) von zwei oder mehr separaten Anwendungen durchgeführt werden. In einigen Ausführungsformen kann die lokale Datenbank 116, die als Teil des Webbrowsers 112 dargestellt wird, eine lokale Datenbank sein, auf die von mehreren Clientanwendungen auf dem Clientgerät zugegriffen werden kann.
Jedes der oben identifizierten Elemente kann in einem oder mehreren der zuvor erwähnten Speichergeräte gespeichert werden und entspricht den Anweisungen für das Durchführen einer oben beschriebenen Funktion. Die oben identifizierten Module oder Programme (d. h. Anweisungen) müssen nicht als separate Softwareprogramme, Verfahren oder Module implementiert werden, weswegen verschiedene Teilmengen dieser Module in verschiedenen Ausführungsformen kombiniert oder anderweitig neu angeordnet werden. In einigen Ausführungsformen kann der Speicher 212 eine Teilmenge der oben identifizierten Module und Datenstrukturen speichern. Zudem kann der Speicher 212 zusätzliche Module und Datenstrukturen speichern, die nicht oben beschrieben sind.
Die Aufmerksamkeit wird nun auf 3 gerichtet, die ein Blockdiagramm beinhaltet, das ein Serversystem 106 gemäß einer Ausführungsform der vorliegenden Erfindung darstellt. Serversystem 106 umfasst in der Regel eine oder mehrere Verarbeitungseinheiten (CPUs) 302, ein oder mehrere Netzwerke oder andere Kommunikationsschnittstellen 304, einen Speicher 312 und einen oder mehrere Kommunikationsbusse 314 zur Verbindung dieser Komponenten. Speicher 312 umfasst einen Highspeed-RAM (Random Access Memory), wie einen DRAM, SRAM, DDR RAM oder andere Solid-State-Speichergeräte mit Direktzugriff, und kann auch einen nichtflüchtigen Speicher umfassen, wie ein oder mehrere Plattenspeicher, optische Speichergeräte, Flash-Speichergeräte oder andere nichtflüchtige Solid-State-Speichergeräte. Speicher 312 kann optional ein oder mehrere Speichergeräte beinhalten, das bzw. die remote von der/den CPU/s 302 angeordnet sind. Speicher 312 oder alternativ der/die permanente/n Speichergerät/e innerhalb des Speichers 312 bestehen aus einem nichtflüchtigen computerlesbaren Datenspeicher. In einigen Ausführungsformen speichert der Speicher 312 oder das computerlesbare Speichermedium des Speichers 312 die folgenden Programme, Module und Datenstrukturen bzw. eine Teilmenge davon:

• ein Betriebssystem 316, das Verfahren zur Abwicklung von verschiedenen grundlegenden Systemdienstleistungen und zur Ausführung von Aufgaben, die von der Hardware abhängen;
• ein Kommunikationsmodul 318, das zum Verbinden des Serversystems 106 mit anderen Computern über eine oder mehrere Kommunikationsschnittstellen 304 (verdrahtet oder drahtlos) und ein oder mehrere Kommunikationsnetzwerke verwendet wird, wie das Internet, andere Wide Area Networks, Local Area Networks, Metropolitan Area Networks und so weiter;
• ein Response-Handler-Modul 320, das Kommunikationen zwischen dem Serversystem 106 und den Clientgeräten 102 weiterleitet. Das Response-Handler-Modul kann in Verbindung mit einem oder anstatt eines separaten Front-End-Servers verwendet werden (108 in 1);
• eine Serveranwendung 110, die Antworten auf Anfragen vorbereitet, die vom Clientgerät 102 empfangen werden. In einigen Ausführungsformen sendet die Serveranwendung 110 die Webanwendung 114 an das Clientgerät 102;
• eine zentrale Datenbank 120 für das Speichern von Datenelementen (z. B. 226-1, 226-2), die mit der Serveranwendung 110 und/oder der Webanwendung 114 verbunden sind;
• ein Prüfsummenrechner (optional) 328 für das Berechnen von Prüfsummen auf einem Datenelement und
• ein Prüfsummen-Comparer (optional) 330 für das Vergleichen einer Prüfsumme, die von einer Webanwendung empfangen wurde, mit einer Prüfsumme, die vom Serversystem 106 berechnet wurde.

Auch wenn 3 ein einzelnes Serversystem 106 zeigt, ist der mit Bezug auf 3 beschriebene Server eher als funktionale Beschreibung der verschiedenen Funktionen, die in einem Serversystem vorhanden sein können, als strukturelles Schema der hier beschriebenen Ausführungsformen vorgesehen. In der Praxis und wie von Fachleuten anerkannt können Elemente, die separat angezeigt werden, kombiniert werden und umgekehrt. Beispielsweise können einige Elemente, die in 3 separat gezeigt werden, auf einem einzelnen Server implementiert sein und einzelne Elemente können von einem oder mehreren Servern implementiert werden. Die tatsächliche Anzahl und die Servertypen, die zur Implementierung eines Serversystems 106 (1) verwendet werden, sowie die Aufteilung der Funktionen unter diesen kann je nach Implementierung unterschiedlich sein und hängt teilweise vom Datenverkehr ab, den das System während Spitzenzeiten und auch während durchschnittlichen Nutzungszeiten bewerkstelligen muss. [0025] Jedes der oben identifizierten Elemente kann in einem oder mehreren der zuvor erwähnten Speichergeräte gespeichert werden und entspricht den Anweisungen für das Durchführen einer oben beschriebenen Funktion. Die oben identifizierten Module oder Programme (d. h. Anweisungen) müssen nicht als separate Softwareprogramme, Verfahren oder Module implementiert werden, weswegen verschiedene Teilmengen dieser Module in verschiedenen Ausführungsformen kombiniert oder anderweitig neu angeordnet werden. In einigen Ausführungsformen speichert Speicher 312 möglicherweise eine Teilmenge der oben identifizierten Module und Datenstrukturen. Zudem kann der Speicher 312 zusätzliche Module und Datenstrukturen speichern, die nicht oben beschrieben sind.
Die Aufmerksamkeit wird nun auf 4 gerichtet, welche die Beziehung zwischen Komponenten eines verteilten Client-Server-Systems gemäß einigen Ausführungsformen zeigt. Wie in 4 gezeigt umfasst das Benutzeroberflächenmodul 228 ein Anzeigemodul 230 für das Rendern der Benutzeroberfläche (z. B auf der Anzeige 206 in 2) und ein Controllermodul 232, um Benutzerinteraktionen zu erkennen (z. B. Mausklicks oder Tastatureingaben über die Tastatur/Maus 208 oder eine berührungsempfindliche Oberfläche 209 in 2) und diese an den Webanwendungsmanager 219 weiterzugeben. In einigen Ausführungsformen ist das Controllermodul 232 als ein Satz von Ereignis-Handlern 402 (z. B. Klick-/Touch-Event-Handler) implementiert werden, die Klicks, Berührungen und andere Benutzereingaben verarbeiten. In einigen Ausführungsformen zeigen alle Ereignis-Handler zunächst Aktivitäten an und senden eine Anfrage an den Webanwendungsmanager 219 (in einigen Ausführungsformen z. B. ein JavaScript-In-Memory-Modell), der ein Modellereignis zurück an das Anzeigemodul 230 sendet. Im Anzeigemodul 230 gibt ein Modellereignis-Handler 406 das Ereignis an einen Benutzeroberflächen-Renderer 408 (z. B. ein HTML-Renderer) und ein Dokumentobjektmodell 410 oder eine andere Anwendungsprogrammier-Schnittstelle für die Bearbeitung von Dokumenten aus. Der Benutzeroberflächen-Renderer 408 sendet gerenderte Benutzeroberflächenelemente an das Dokumentobjektmodell 410, welches ein neues Modell erstellt, dieses anzeigt (z. B. dem Benutzer) und es an das Controllermodul 232 ausgibt, um auf zusätzliche Ereignisse zu warten, die von den Ereignis-Handlern 402 erkannt werden.
In einigen Ausführungsformen, wenn der Webanwendungsmanager 219 so konfiguriert ist, dass er ein Ereignis vom Ereignis-Handler 402 erkennt, der angibt, dass eine Operation auf einer oder mehreren Datenelementen in der lokalen Datenbank 116 durchgeführt werden muss, sendet der Webanwendungsmanager 219 die Operation an die Warteschlange für Schreibanfragen 220. In einigen Ausführungsformen werden die Operationen 412-1, 412-2, 412-3, 412-4, 412-5, 412-6 in der Warteschlange für Schreibanfragen 220 in der Reihenfolge, in der sie in der Warteschlange für Schreibanfragen 220 eintreffen, gespeichert (d. h. in diesen Ausführungsformen ist die Warteschlange für Schreibanfragen ist eine chronologische Aufzeichnung der Anfragen vom Webanwendungsmanager 219). Der Webanwendungsmanager pflegt eine Liste der Callbacks in das Benutzeroberflächenmodul 228, eine für jede Operation (z. B. „Operation 1” 412-1) in der Warteschlange für Schreibanfragen, wobei mit einer Kennzeichnung angegeben wird, ob der Callback aufgerufen wurde oder nicht, und eine Zählung für alle fehlgeschlagenen Versuche, die Operation zu erfüllen (z. B. „Operation 1” 412-1). In einigen Ausführungsformen ist der Aktions-Dispatcher 222 so konfiguriert, dass er Operationen (z. B. „Operation 1” 412-1) von der Warteschlange für Schreibanfragen 220 an die lokale Datenbank 116 und das Kommunikationsmodul 218 sendet.
In einigen Ausführungsformen ist der Aktions-Dispatcher 222 so konfiguriert, dass er Operationen an einen Prüfsummenrechner sendet. Der Prüfsummenrechner berechnet die Prüfsumme eines oder mehrerer Datenelemente, die in der lokalen Datenbank 116 gespeichert sind. In einigen Ausführungsformen wird die Prüfsumme zusammen mit dem Datenelement in der lokalen Datenbank 116 gespeichert. Wenn bereits eine Prüfsumme für das Datenelement in der lokalen Datenbank 116 gespeichert war, ersetzt die berechnete Prüfsumme die zuvor gespeicherte. In einigen Ausführungsformen werden Prüfsummen unter Verwendung des gesamten Datenelements berechnet. Eine Prüfsumme kann mit allen bekannten Standardverfahren berechnet werden (z. B. der MD5-Prüfsummenalgorithmus (IETF RFC 1321) oder der SHA-1(FIPS PUB 180-1)-Algorithmus). In einigen Ausführungsformen, die weiter unten mit Bezug auf die 8A–8C näher erläutert werden, werden Prüfsummen für ein Datenelement verwendet, um zu bestimmen, ob das Datenelement aktualisiert wurde.
In einigen Ausführungsformen überträgt das Kommunikationsmodul 218 die vom Aktions-Dispatcher 222 empfangenen Operationen (z. B. „Operation 1 412-1) an das Response-Handler-Modul 320 im Serversystem. In einigen Ausführungsformen gibt das Response-Handler-Modul 320 die Operation an die Serveranwendung 110 aus. Die Serveranwendung 110 ist in einigen Ausführungsformen so konfiguriert, dass sie ein oder mehrere Datenelemente auf Anfrage aus einer zentralen Datenbank 120 abruft, um die Operation durchzuführen (z. B. wird ein eindeutiger Identifier verwendet, der dem in der Anfrage enthaltenen Datenelement zugeordnet ist). In einigen Ausführungsformen gibt die Serveranwendung 110 die Ergebnisse (z. B. ein Datenelement und/oder eine Prüfsumme eines Datenelements) der Operation an den Response-Handler 320 zurück, der die Ergebnisse an das Clientgerät 102 übermittelt. In einigen Ausführungsformen, wenn die lokale Datenbank 116 nicht mit der zentralen Datenbank 120 synchronisiert ist (d. h. nicht kohärent ist), beinhaltet die Antwort ein Ersatzdatenelement oder eine Komponente eines Datenelements, das bzw. die benötigt wird, um die lokale Datenbank 116 wieder mit der zentralen Datenbank 116 kohärent zu machen. In einigen Ausführungsformen, wenn die lokale Datenbank 116 mit der zentralen Datenbank 120 synchronisiert ist (d. h. kohärent ist), gibt die Antwort an, dass die Datenelemente in der lokalen Datenbank 116 auf dem neuesten Stand sind (z. B. beinhaltet die Antwort keine Datenelemente oder Komponenten von Datenelementen).
In einigen Ausführungsformen gibt das Kommunikationsmodul 218 auf dem Clientgerät 102 die Ergebnisse von der Serveranwendung 110 an ein Response-Handler-Modul 234 auf dem Clientgerät aus. In einigen Ausführungsformen werden die Ergebnisse der Operation in der lokalen Datenbank 116 gespeichert und/oder an den Webanwendungsmanager 219 zurückgegeben. In einigen Ausführungsformen ist die Operation eine Anzeigeoperation und das Datenelement wird dem Benutzer angezeigt.
Betrachten wir zum Beispiel ein Szenario, in dem ein Benutzer eine E-Mail-Anwendung auf einem Mobilgerät anzeigt und den Header der E-Mail auswählt, um diese anzuzeigen. In diesem Beispiel wird die Anfrage zur Anzeige der E-Mail-Nachricht auf einem Mobilgerät vom Webanwendungsmanager 219 an die Warteschlange für Schreibanfragen 220 gesendet. Wenn der Aktions-Dispatcher 222 die E-Mail in der lokalen Datenbank 116 findet, wird die E-Mail zur Anzeige für den Benutzer an den Webanwendungsmanager 219 gesendet. Findet der Aktions-Dispatcher 222 die E-Mail nicht in der lokalen Datenbank 116, wird die Anfrage für die Nachricht an ein Serversystem 106 mit einer E-Mail-Datenbank 120 gesendet und die E-Mail von der zentralen Datenbank 120 wird an das Clientgerät 102 zurückgegeben. In dieser Ausführungsform wird die E-Mail-Nachricht an den Response-Handler 234 zurückgegeben, der die E-Mail in der lokalen Datenbank 116 speichert und zur Anzeige für den Benutzer an den Webanwendungsmanager 219 ausgibt.
Die Aufmerksamkeit wird nun auf die 5A–5C gerichtet, in denen der Startvorgang einer Multi-Thread-Softwareanwendung in einem verteilten Client-Server-System gemäß einigen Ausführungsformen dargestellt wird.
Um die Startup-Kosten am Client 102 zu reduzieren, unterteilt die Multi-Thread-Softwareanwendung den Prozess in mehrere Phasen, wie in den 5A–5C dargestellt. In der Initialisierungsphase 510 startet die Softwareanwendung zuerst eine Hauptanwendung auf einem Haupt-Thread 502. In einigen Ausführungsformen ist die Softwareanwendung der webbasierte E-Mail-Dienst auf einem tragbaren Gerät, wie einem Mobiltelefon. Die Hauptanwendung auf dem Haupt-Thread ist verantwortlich für die Verarbeitung von Benutzerinteraktionen mit der Benutzeroberfläche des Dienstes. In einigen Ausführungsformen läuft die Hauptanwendung in einem einzelnen Thread. In anderen Ausführungsformen ist die Hauptanwendung „multi-threaded”.
Wie in 5A dargestellt, gibt es nach der Initialisierung eine synchrone Verbindung 506 zwischen dem Haupt-Thread 502 und einer lokalen Datenbank 118. Die lokale Datenbank 118 speichert eine vordefinierte Datenmenge zwischen, die dem E-Mail-Dienst zugeordnet ist. Eine detailliertere Beschreibung der lokalen Datenbank wird unten in Zusammenhang mit 6B geboten. Über die synchrone Verbindung 506 kann die Hauptanwendung am Haupt-Thread 502 Operationen auf der lokalen Datenbank 118 synchron ausführen. Dazu gehört zum Beispiel das Abrufen von Datensätzen aus der lokalen Datenbank 118 und das Hochladen von Datensätzen in die lokale Datenbank 118.
Es gibt auch eine asynchrone Verbindung 514 zwischen dem Haupt-Thread 502 und der Serveranwendung 322 in einem Remote-Serversystem 106. Als Teil einer webbasierten Softwareanwendung kommen alle E-Mail-Nachrichten, die von der Hauptanwendung am Client 102 gerendert werden, letztendlich von der Serveranwendung 322, die die E-Mail-Nachrichten in einer zentralen Datenbank 120 auf Serverseite verwaltet. Eine detailliertere Beschreibung der Serveranwendung 322 und der zentralen Datenbank 120 wird unten in Zusammenhang mit den 6A und 7A–7B geboten. Wie nachstehend erklärt wird, verwendet die Hauptanwendung die asynchrone Verbindung 514, um Daten von der zentralen Datenbank 120 abzurufen, wenn diese nicht in der lokalen Datenbank 118 vorhanden sind.
In einigen Ausführungsformen umfasst die Initialisierung der Hauptanwendung am Haupt-Thread 502 die Anzeige einer Benutzeroberfläche am Client 102, das Abrufen einer vordefinierten Datenmenge von der lokalen Datenbank 118 und das Befüllen der Benutzeroberfläche mit den abgerufenen Daten. Beispiel: Während der Initialisierung eines webbasierten E-Mail-Dienstes verwendet die Hauptanwendung auf dem Haupt-Thread 502 die synchrone Verbindung 506, um E-Mail-Nachrichten, die mit dem Posteingang des E-Mail-Kontos eines Benutzers verbunden sind, aus der lokalen Datenbank 118 abzurufen, da angenommen wird, dass ein durchschnittlicher Benutzer des E-Mail-Dienstes zuerst die ungelesenen Nachrichten seinem Posteingang lesen möchte. Nachdem die Nachrichten über die synchrone Verbindung 506 von der lokalen Datenbank 118 abgerufen wurden, befüllt die Hauptanwendung die mit dem E-Mail-Dienst verbundene Benutzeroberfläche mit den abgerufenen Nachrichten, damit der Benutzer von Client 102 zumindest mit den Nachrichten im Posteingang interagieren kann. Auch wenn die Initialisierung der Hauptanwendung, wie in 5A gezeigt, den Start des gesamten E-Mail-Dienstes möglicherweise nicht abschließt, kann die Möglichkeit, so schnell wie möglich auf die ungelesenen Nachrichten im Posteingang zuzugreifen, die Erfahrung des durchschnittlichen Benutzers mit dem E-Mail-Dienst wesentlich verbessern.
Neben der Befüllung des Posteingangs kann der Startvorgang des E-Mail-Dienstes auch andere Aufgaben umfassen, wie das Abrufen von E-Mail-Nachrichten, die mit anderen Ordnern verbunden sind, aus der lokalen Datenbank 118 und das Synchronisieren der lokalen Datenbank 118 mit der zentralen Datenbank 120. Daher kann der Abschluss des gesamten Startvorgangs eine wesentliche Menge an Datenübertragungen zwischen verschiedenen Komponenten im Client 102 und zwischen dem Client 102 und dem Server 106 umfassen. Wenn der Haupt-Thread 502 auch für die Verarbeitung dieser Aufgaben verantwortlich ist, kann er die Benutzeroberfläche möglicherweise nicht aufrufen und zeitnah für den Empfang der Benutzeranweisungen bereit sein.
In einigen Ausführungsformen folgt daher auf die Initialisierungsphase 510, die dem Benutzer den Eindruck vermittelt, dass der E-Mail-Dienst bereit ist, eine zweite Phase 520, z. B., wobei ein unterstützender Vorgang auf einem sekundären Thread 504 initialisiert wird. Indem der Start des sekundären Thread 504 verzögert wird, wird die Latenz, die dadurch verursacht wird, dass der Haupt-Thread 502 für den gesamten Startvorgang verantwortlich ist, verhindert oder zumindest wesentlich verringert.
Wie in 5B gezeigt, bringt der Haupt-Thread 502 den sekundären Thread 504 hervor, nachdem die Hauptanwendung am Haupt-Thread 502 eine Transaktion zwischen dem Haupt-Thread 502 und der lokalen Datenbank 116 abschließt, z. B. indem der Posteingang des E-Mail-Dienstes befüllt wird. Es ist zu beachten, dass der unterstützende Vorgang am sekundären Thread 504 erzeugt wird, um die Hauptanwendung am Haupt-Thread 502 zu ersetzen, damit mit der lokalen Datenbank 118 kommuniziert werden kann und die verbleibenden Aufgaben zum Starten der webbasierten E-Mail-Dienstanwendung abgeschlossen werden können. Es gibt auch eine synchrone Verbindung 512 zwischen dem sekundären Thread 504 und der lokalen Datenbank 116. Über diese Verbindung 512 kann der unterstützende Vorgang die gleichen Operationen auf der lokalen Datenbank 118 durchführen, die die Hauptanwendung über die Verbindung 506 durchführen kann. In einigen Ausführungsformen erfüllt der unterstützende Vorgang die Aufgaben zur Initialisierung der webbasierten Anwendung, die von der Hauptanwendung übriggelassen wurden. In einigen anderen Ausführungsformen erfüllt die Hauptanwendung alle Aufgaben, die mit dem Initialisieren der webbasierten Anwendung verbunden sind. Daher ist der unterstützende Vorgang hauptsächlich dafür verantwortlich, die Rolle der Interaktion mit der lokalen Datenbank 118, die vom Haupt-Thread 502 übernommen wurde, zu ersetzen.
Wie in 5C gezeigt, gibt es eine asynchrone Verbindung 508 zwischen dem Haupt-Thread 502 und dem sekundären Thread 504. Durch den Aufbau der synchronen Verbindung 512 muss die Hauptanwendung keine Operationen auf der lokalen Datenbank 116 mehr direkt über die synchrone Verbindung 506 durchführen, wie es während der Initialisierungsphase 510 der Fall war. Stattdessen geht die gesamte Anwendung nun die Phase 530 des stabilen Betriebs über. Während des stabilen Betriebs kommuniziert die Hauptanwendung mit dem unterstützenden Prozess am sekundären Thread 504 über die asynchrone Verbindung 508. Dadurch wird in einigen Ausführungsformen die synchrone Verbindung 506 zwischen dem Haupt-Thread 502 und der lokalen Datenbank 116 beendet oder zerstört (wie durch die gestrichelte Linie in 5C dargestellt). in einigen anderen Ausführungsformen ist die synchrone Verbindung 506 noch vorhanden, jedoch deaktiviert.
Die Aufmerksamkeit wird nun auf 6A gerichtet, in der die Datenstrukturen in einem mit einer Webanwendung verbundenen Serversystem gemäß einigen Ausführungsformen dargestellt werden. in einigen Ausführungsformen umfasst die zentrale Datenbank 120 ein Serververzeichnis 602. Das Serververzeichnis 602 ist eine Zuordnungstabelle, die einen eindeutigen Identifier (z. B. „Eindeutige ID” 604-1) dem Status (z. B. „Status” 606-1) des Datenelements (z. B. Datenelement 1 226-1) zuordnet und eine Referenz (z. B. „Referenz 1” 608-1) dem Datenelement zuweist.
In einigen Ausführungsformen beinhaltet der eindeutige Identifier (z. B. „Eindeutige ID” 604-N) einen Datenelementtyp 609 und einen Datenelement-Identifier 610. In einigen Ausführungsformen gibt der Datenelementtyp 609 den Typ des Datenelements an, auf das vom eindeutigen Identifier verwiesen wird. Wenn das Datenelement beispielsweise eine Konversation ist (z. B. eine Liste von Nachrichten), beinhaltet der Datenelementtyp 609 „conversation” oder einen entsprechenden alphanumerischen Tag. Wenn das Datenelement eine Thread-Liste ist (z. B. eine Liste von Konversationen), beinhaltet der Datenelementtyp 609 „thread list” oder einen entsprechenden alphanumerischen Tag. Alternativ beinhaltet der Datenelementtyp 609 den Namen der Thread-Liste, wenn das Datenelement eine Thread-Liste ist (z. B. eine Liste von Konversationen). Wenn die Thread-Liste beispielsweise ein E-Mail-Postfach ist, beinhaltet der Datenelementtyp den alphanumerischen Tag „inbox”. Wenn die Thread-Liste mehrere Konversationen beinhaltet, die mit der Bezeichnung „work” verbunden sind, beinhaltet der Datenelementtyp den alphanumerischen Tag „work”. in einigen Ausführungsformen kann der Datenelementtyp-Identifier eine Kombination aus den Datenelementtyp-Identifiern sein.
In einigen Ausführungsformen ist der Datenelement-Identifier ein Identifier, der das Datenelement eines bestimmten Typs (z. B. wenn der Datenelementtyp 609 „conversation” oder wenn der Datenelementtyp 609 „message” ist) eindeutig in einer Teilmenge von Datenelementen identifiziert. In einigen Ausführungsformen ist der Datenelement-Identifier beispielsweise eine Konversations-ID (z. B. 620) oder eine Nachrichten-ID. In Ausführungsformen, in denen das Datenelement eine Konversation ist (z. B. eine Liste von Nachrichten), ist der Datenelement-Identifier der Nachrichten-Identifier der ersten Nachricht in der Nachrichtenliste.
In einigen Ausführungsformen weist der Status (z. B. 606-1) eines Datenelements (z. B. 226-1) auf den Zeitpunkt hin, zu dem das Datenelement zuletzt aktualisiert (z. B. durch ein neues Datenelement ersetzt wurde) oder geändert wurde bzw. zu dem zuletzt darauf zugegriffen wurde (z. B. angezeigt, kopiert, gesendet usw.). Der Status wird aktualisiert, wenn eine Operation auf dem Datenelement durchgeführt wird.
In einigen Ausführungsformen ist die Referenz auf ein Datenelement eine Referenz auf eine Relationstabelle 611, die eine Referenz vom Datenelement auf jede Komponente des Datenelements beinhaltet. in einigen Ausführungsformen hat das Datenelement mehrere Komponenten. Beispiel: Referenz 1 608-1 im Serververzeichnis 602 verweist auf zwei Einträge in der Relationstabelle 611 für das Datenelement 1 226-1: Thread 1 612-1 und Thread 2 612-2. (Diese Situation entsteht, da diese beiden Konversationen/Threads jeweils mit der Thread-Liste verbunden sind, die von der Referenz 608-1 identifiziert wird). In einigen Ausführungsformen hat das Datenelement eine einzelne Komponente. Beispiel: Referenz 2 608-2 verweist auf einen einzelnen Eintrag in der Relationstabelle 611 für das Datenelement 2 226-2: Thread 2 612-2. in einigen Ausführungsformen beinhaltet eine Gruppe von verschiedenen Datenelementen eine gemeinsame Komponente. Beispiel: Datenelement 1 226-1 und Datenelement 2 226-2 beziehen sich jeweils auf Thread 2 612-2 in der Relationstabelle 611. Mit anderen Worten kann eine einzelne Konversation (z. B. eine Liste von Nachrichten) in mehreren Thread-Listen vorhanden sein. In einer Ausführungsform, in der die Webanwendung eine webbasierte E-Mail-Anwendung ist und E-Mail-Nachrichten in Konversationen angeordnet sind (z. B sortierte Listen von E-Mail-Nachrichten), kann eine oder mehrere Konversationen eine Vielzahl an Bezeichnungen beinhalten, wobei jede Bezeichnung mit einer Thread-Liste verbunden ist (z. B. eine Konversation, die die Bezeichnung „inbox” beinhaltet, und die Bezeichnung „work” mit der Thread-Liste „inbox” und der Thread-Liste „work” verbunden ist).
In einigen Ausführungsformen sind die Komponenten Nachrichten. Wie oben beschrieben, kann das Datenelement eine einzelne oder mehrere Komponenten beinhalten. Beispiel: Referenz 3 608-3 (welche eine Referenz für eine Konversation ist) verweist auf drei Einträge in der Relationstabelle 611 für das Datenelement 3 226-3: Nachricht 1 614-1, Nachricht 2 614-2 und Nachricht 3 614-3, während Referenz N 608-N auf einen einzelnen Eintrag in der Relationstabelle Datenelement-N 226-N (z. B. Nachricht Q 614-Q) verweist.
In einigen Ausführungsformen, wenn in der Relationstabelle eine Beziehung zu einem Thread besteht (z. B. Thread 1 612-1), verweist die Beziehung auf eine Tabelle von Threads 616, einschließlich einer Vielzahl von Threads (z. B. Thread 1 612-1, Thread 2 612-2, Thread P 612-P). In der Tabelle von Threads 616 ist jeder Thread mit einem Konversations-Identifier 620 und einer Konversationsinformation 622 zum Thread verbunden. Der Konversations-Identifier 620 ist ein Identifier, der vom Systemserver zum Identifizieren von Nachrichten verwendet wird, die mit der Konversation verbunden sind. In einigen Ausführungsformen beinhaltet die Konversationsinformation 622 den Betreff der Nachricht, die in der Konversation beinhalten ist – ein kurzer „Snippet”, der die aktuelle Nachricht in der Konversation und/oder der Liste der Nachrichten zusammenfasst.
In einigen Ausführungsformen, wenn in der Relationstabelle eine Beziehung zu einer Nachricht besteht (z. B. Nachricht 1 614-1), verweist die Beziehung auf eine Tabelle an Nachrichten 618, einschließlich einer Vielzahl von Nachrichten (z. B. Nachricht 1 614-1, Nachricht 2, 614-2, Nachricht 3 614-3, Nachricht Q 614-Q). In der Tabelle von Nachrichten 618 ist jede Nachricht mit der Nachrichteninformation 624 über die Nachricht verbunden. In einigen Ausführungsformen beinhaltet die Nachrichteninformation 624 den Text der Nachricht, die Anhänge beinhaltet.
Die Aufmerksamkeit wird nun auf 6B gerichtet, in der Daten darstellt werden, die mit einer Webanwendung in einem Clientgerät gemäß einigen Ausführungsformen verbunden sind. In einigen Ausführungsformen beinhaltet die lokale Datenbank 116 ein Clientverzeichnis 652. Das Clientverzeichnis 652 ist eine Zuordnungstabelle, die einen eindeutigen Identifier (z. B. „Eindeutige ID” 604-1) dem Status (z. B. „Status” 656-1) des Datenelements (z. B. Datenelement 1 226-1) zuordnet und eine Referenz (z. B. „Referenz 1” 660-1) dem Datenelement zuweist. In einigen Ausführungsformen, in denen Prüfsummen (z. B. 658-1, 658-2, 658-3, 658-M) zur Beibehaltung der Cache-Kohärenz verwendet werden, wird eine Prüfsumme für jedes Datenelement (z. B. 226-1, eine Prüfsumme, z. B. 658-1) in der lokalen Datenbank 116 gespeichert und dem Datenelement zugeordnet. In der in 6B dargestellten Ausführungsform wird die Prüfsumme (z. B. 658-1) im Clientverzeichnis 652 gespeichert. Es sollte jedoch verstanden werden, dass die Prüfsummen in einem anderen Teil der lokalen Datenbank 116 gespeichert werden können.
In einigen Ausführungsformen beinhaltet der eindeutige Identifier (z. B. „Eindeutige ID” 604-N) einen Datenelementtyp 609 und einen Datenelement-Identifier 610, wie oben im Detail mit Bezug auf 6A beschrieben. In einigen Ausführungsformen ist ein eindeutiger Identifier auf dem Server (z. B. „Eindeutige ID” 604-1 in 6A) identisch mit einem eindeutigen Identifier auf dem Client (z. B. „Eindeutige ID” 604-1 in 6B) und gibt an, dass beide eindeutigen Identifier mit dem gleichen Datenelement verbunden sind.
In einigen Ausführungsformen weist der Status (z. B. 656-1) eines Datenelements (z. B. 226-1) auf den Zeitpunkt hin, zu dem das Datenelement zuletzt aktualisiert (z. B. durch ein neues Datenelement ersetzt wurde) oder geändert wurde bzw. zu dem zuletzt darauf zugegriffen wurde (z. B. angezeigt, kopiert, gesendet usw.). Der Status wird aktualisiert, wenn eine Operation auf dem Datenelement durchgeführt wird. In einigen Ausführungsformen sind der Status eines Datenelements auf dem Server (z. B. 606-2 in 6A) und der Status des gleichen Datenelements auf dem Client (z. B. 656-2 in 6B) identisch (z. B. wenn die lokale Datenbank und die zentrale Datenbank synchronisiert sind). In einigen Ausführungsformen sind der Status eines Datenelements auf dem Server (z. B. 606-3 in 6A) und der Status des gleichen Datenelements auf dem Client (z. B. 656-3 in 6B) unterschiedlich (z. B. wenn die lokale Datenbank und die zentrale Datenbank nicht synchronisiert sind).
In einigen Ausführungsformen ist die Referenz auf ein Datenelement eine Referenz auf eine Relationstabelle 666, die eine Beziehung zwischen dem Datenelement und jeder Komponente des Datenelements beinhaltet. In einigen Ausführungsformen hat das Datenelement mehrere Komponenten. Beispiel: Die Referenz 1 660-1 im Clientverzeichnis 652 bezieht sich auf zwei Einträge in der Relationstabelle 666 für Datenelement 1 226-1: Thread 1 668-1 und Thread 2 668-2. (Diese Situation entsteht, da diese beiden Konversationen/Threads jeweils mit der Thread-Liste verbunden sind, die von der Referenz 608-1 identifiziert wird). In einigen Ausführungsformen hat das Datenelement eine einzelne Komponente (Beispiel: Referenz 2 660-2 bezieht sich auf einen einzelnen Eintrag in der Relationstabelle 666 für Datenelement 2 226-2: Thread 2 668-2). In einigen Ausführungsformen beinhaltet eine Gruppe von verschiedenen Datenelementen eine gemeinsame Komponente. Beispiel: Datenelement 1 und Datenelement 2 beinhalten jeweils einen Bezug auf Thread 2 668-2. Mit anderen Worten kann eine einzelne Konversation (z. B. eine Liste von Nachrichten) in mehreren Thread-Listen vorhanden sein. In einer Ausführungsform, in der die Webanwendung eine mobile E-Mail-Anwendung ist und E-Mail-Nachrichten in Konversationen angeordnet sind, kann eine oder mehrere Konversationen eine Vielzahl an Bezeichnungen beinhalten, wobei jede Bezeichnung mit einer Thread-Liste verbunden ist (z. B. eine Konversation, die die Bezeichnung „inbox” beinhaltet, und die Bezeichnung „work” mit der Thread-Liste „inbox” und der Thread-Liste „work” verbunden ist).
In einigen Ausführungsformen sind die Komponenten Nachrichten. Wie oben beschrieben, kann das Datenelement eine einzelne oder mehrere Komponenten beinhalten. Beispielsweise bezieht sich Referenz 3 660-3 (welche ein Verweis auf eine Konversation ist) auf zwei Beiträge in der Relationstabelle 666 für Datenelement 3 226-3: Nachricht 1 670-1 und Nachricht 2 670-2, während sich Referenz M 660-M auf einen einzelnen Eintrag in der Relationstabelle Datenelement M 226-M bezieht (z. B. „Nachricht S” 670-S).
In einigen Ausführungsformen, wenn in der Referenztabelle eine Beziehung zu einem Thread besteht (z. B. Thread 1 668-1), verweist die Referenz auf eine Tabelle von Threads 672, einschließlich einer Vielzahl von Threads (z. B. Thread 1 668-1, Thread 2 668-2, Thread R 668-R). In der Threads-Tabelle 672 ist jeder Thread mit einem Konversations-Identifier 676 und der Konversationsinformation 678 über die Thread verbunden. Der Konversations-Identifier 676 ist ein Identifier, der vom Clientgerät zum Identifizieren von Nachrichten verwendet wird, die mit der Konversation verbunden sind (z. B. eine Liste von Nachrichten). In einigen Ausführungsformen beinhaltet die Konversationsinformation 678 den Betreff der Nachrichten, die in der Konversation beinhalten sind – ein kurzer „Snippet”, der die aktuelle Nachricht in der Konversation und/oder der Liste der Nachrichten zusammenfasst.
In einigen Ausführungsformen, wenn in der Referenztabelle eine Beziehung zu einer Nachricht besteht (z. B. Nachricht 1 670-1), verweist die Referenz auf eine Tabelle von Nachrichten 674, einschließlich einer Vielzahl von Nachrichten (z. B. Nachricht 1 670-1, Nachricht 2 670-2, Nachricht S 670-S). In der Nachrichtentabelle 674 ist jede Nachricht mit der Nachrichteninformation 680 über die Nachricht verbunden. In einigen Ausführungsformen beinhaltet die Nachrichteninformation 680 den Text einer Nachricht, die Anhänge beinhaltet.
In einigen Ausführungsformen, wie in den 6A und 6B dargestellt, haben die zentrale Datenbank 120 in 6A und die lokale Datenbank 116 in 6B ähnliche Datenstrukturen. Die in diesen Datenstrukturen gespeicherten Daten sind jedoch nicht immer identisch. In einigen Ausführungsformen haben die zentrale Datenbank 120 in 6A und die lokale Datenbank 116 in 6B verschiedene Datenelemente, Nachrichten und Threads, die in ihren entsprechenden Datenstrukturen gespeichert sind. In einigen Ausführungsformen wurden die Datenelemente, Nachrichten und Threads in der lokalen Datenbank 116 in 6B und der zentralen Datenbank 120 in 6A synchronisiert (z. B. wurden sie kohärent gemacht) und sind identisch. Gemäß einigen Ausführungsformen werden Verfahren offenbart, die erkennen, wenn die lokale Datenbank 116 in 6B und die zentrale Datenbank 120 in 6A nicht synchronisiert sind, sowie Verfahren für das Synchronisieren der Datenbanken, wie unten ausführlicher mit Verweis auf die 8A–8C beschrieben.
Beispiel: In 6A hat die zentrale Datenbank N Datenelemente, P Threads und Q Nachrichten (wobei N, P und Q alle Ganzzahlen größer 0 darstellen), während die lokale Datenbank 116 in 6B M Datenelemente, R Threads und S Nachrichten hat (wobei M, R und S alle Ganzzahlen größer 0 darstellen). In einigen Ausführungsformen sind N = M, P = R, Q = S und die Datenstrukturen in der zentralen Datenbank 120 in 6A speichern Informationen, die mit den Datenstrukturen identisch sind, in der lokalen Datenbank 116 in 6B. In einigen Ausführungsformen beinhaltet die zentrale Datenbank 120 in 6A zusätzliche Daten, die nicht in der lokalen Datenbank 116 in 6B beinhalten sind, und/oder die lokale Datenbank 116 in 6B beinhaltet zusätzliche Daten, die nicht in der zentralen Datenbank 120 in 6A beinhalten sind (z. B. ist die zentrale Datenbank mit einem webbasierten E-Mail-Server verbunden, der eine oder mehrere neue E-Mail-Nachrichten beinhaltet, während das Clientgerät nicht mit dem E-Mail-Server verbunden ist. Die zentrale Datenbank beinhaltet daher eine oder mehrere neue E-Mail-Nachrichten, die nicht in der lokalen Datenbank beinhalten sind).
Zudem ist zu beachten, dass in einigen Ausführungsformen Prüfsummen 658-1 in der lokalen Datenbank 116 in 6B gespeichert sind, während sie nicht in der zentralen Datenbank 120 in 6A gespeichert sind. Wie ausführlicher unten mit Bezug auf die 8A–8C beschrieben, werden Prüfsummen eher „on-the-fly” vom Serversystem berechnet (z. B. bei Bedarf) und sind daher nicht in der zentralen Datenbank 120 in 6A gespeichert.
Obwohl hier zu Illustrationszwecken exemplarische Datenstrukturen beschrieben wurden, sollte verstanden werden, dass an ihrer Stelle alternative Datenstrukturen verwendet werden können, um Datenelemente und zugehörige Informationen zu den oben beschriebenen Datenelementen zu speichern. In einigen Ausführungsformen werden mehrere Server mit mehreren Datenbanken verwendet, um die Datenelemente auf dem Serversystem zu speichern, und verschiedene Datenstrukturen, die speziell an solche verteilten Systeme angepasst sind, können verwendet werden. In einer solchen wechselnden Ausführungsform werden Datenstrukturen wie die in der US-Patentpublikation Nr. 2005/0222985 A1 (welche hierbei durch Verweis in ihrer Gesamtheit einbezogen ist) beschriebenen verwendet, um die Datenelemente, Konversationen und zugehörigen Informationen zu speichern, die als in der zentralen Datenbank 120 gespeichert beschrieben werden. Beispiel: In einer webbasierten E-Mail-Anwendung können E-Mail-Konversationen und andere zugehörige Informationen in Datenstrukturen gespeichert werden, die speziell angepasst sind, um zwischen einer Vielzahl von Servern und Datenbanken verteilt zu werden, um die Zugriffsgeschwindigkeit und Fehlertoleranz zu verbessern.
Die Aufmerksamkeit wird nun auf die 7A–7B gerichtet, in denen Client- und Serverrollen beim Übertragen von Daten zwischen einer persistenten Webanwendung auf einem Client- und einem Serversystem gemäß einigen Ausführungsformen dargestellt werden. Der Client (102 in 2) hat eine Clientanwendung (z. B. Webbrowser 112 in 2), einschließlich einer lokalen Webanwendung (z. B. 114 in 2). In einigen Ausführungsformen hat die lokale Webanwendung (z. B. 114 in 2) Online- und Offline-Modi. Wenn die Webanwendung beispielsweise ein webbasiertes E-Mail-Programm ist, kann das Programm einige der häufig verwendeten E-Mail-Nachrichten (z. B. Datenelement 226-1 in 2) in einer lokalen Datenbank speichern (z. B. 116 in 2).
Der Prozess beginnt, wenn die Webanwendung Zugriff (702) auf ein Datenelement benötigt, wie eine elektronische Nachricht (z. B. eine E-Mail), eine Konversation (z. B. eine Liste von elektronischen Nachrichten) oder eine Thread-Liste (z. B. eine Liste von Konversationen). In einem Beispiel empfängt die Webanwendung eine Anfrage von einem Benutzer zur Anzeige, zum Senden oder zum Bearbeiten des Datenelement bzw. zur Durchführung einer anderen Operation auf dem Datenelement. Der Client prüft, ob sich das Datenelement in der lokalen Datenbank befindet. Wenn das Datenelement (704) in der lokalen Datenbank gefunden wird, wird aus der dieser abgerufen (706) und die Webanwendung empfängt (708) das Datenelement.
In einigen Ausführungsformen ist die Webanwendung eine webbasierte E-Mail-Anwendung (z. B. GMail) mit Offline-Fähigkeiten (z. B. eine persistente webbasierte Anwendung). Wenn der Client zum Beispiel Zugriff auf eine Netzwerkverbindung hat, verhält sich die Webanwendung genau wie eine normale webbasierte E-Mail-Schnittstelle, an der sich der Benutzer bei einer Webseite anmeldet und E-Mail-Nachrichten abruft und andere Operationen durchführt. In einigen Ausführungsformen hat das webbasierte E-Mail-Programm Offline-Funktionen, da es auf eine lokale Datenbank zugreifen kann, die zum Speichern einiger E-Mail-Nachrichten verwendet wird, auf die am ehesten von der Webanwendung und anderen lokalen Anwendungsdaten zugegriffen wird. Wenn der Client keinen Zugriff auf eine Netzwerkverbindung hat und der Benutzer versucht, über den Webbrowser auf das webbasierte E-Mail-Programm zuzugreifen, lässt die Webanwendung nach wie vor zu, dass der Benutzer auf die E-Mails zugreift, die in der lokalen Datenbank gespeichert sind, und Operationen auf den in der lokalen Datenbank gespeicherten E-Mails durchführt.
In einigen Ausführungsformen (z. B. in denen die Netzwerklatenz hoch ist) ist es wünschenswert, einige Datenelemente in einer lokalen Datenbank zu speichern, um die Verzögerung zwischen dem Empfang einer Benutzereingabe und der Durchführung einer durch die Eingabe angegebenen Operation (z. B. Anzeigen) auf einem oder mehreren Datenelementen zu verringern. Eine lokale Datenbank kann also als Cache für Datenelemente dienen, sodass Anweisungen von der Webanwendung auf den Datenelementen in der lokalen Datenbank durchgeführt werden können, bevor eine Antwort vom Serversystem empfangen werden. Diese Struktur ist analog zu einem Hardware-Cache, der mit einem Mikroprozessor verbunden ist, der zur Beschleunigung der Verarbeitungsoperationen in einem Hardwaresystem verwendet wird, indem die zu verwendeten Daten vom Prozessor zwischengespeichert werden, wodurch die Auswirkungen der Kommunikationslatenz zwischen Anfragen für Daten und dem Empfang der angefragten Daten vom Mikroprozessor verringert werden.
In einigen Ausführungsformen wird das Dokumentobjektmodell des Webbrowsers als L1-Cache verwendet. Wie von den in Hardware vorhandenen Cache-Typen vorgeschlagen, kann Software mit einem als L1-Cache verwendeten Dokumentobjektmodell vom Typ „Write-Back” oder „Write-Through” sein. In einigen Ausführungsformen ist ein Write-Back-Cache der Dokumentobjektmodell-Fragmente als L1-Cache passend, wenn die Webanwendung einige Benutzeraktionen durch direktes Bearbeiten des Dokumentobjektmodells implementiert. Zu den anderen Funktionen in der Ausführungsform, die durch diese Analogie mit Hardware-Caching vorgeschlagen werden, gehören das Prefetching von Datenelementen und das Load Forwarding (also wenn Antworten vom Server direkt an den Webbrowser 112 zur Anzeige auf dem Display 206 weitergeleitet werden, bevor sie in die lokale Datenbank 116 geschrieben werden).
In einigen Ausführungsformen wird die Warteschlange für Schreibanfragen 220 im nichtflüchtigen Speicher gespeichert, sodass, selbst wenn die Webanwendung oder der Webbrowser, auf dem die Webanwendung ausgeführt wird, abstürzt, sämtliche Operationen, die bis zu diesem Punkt von der Webanwendung in die Warteschlange für Schreibanfragen geschrieben wurden, erhalten bleiben.
In einigen Ausführungsformen befindet sich ein angefragtes Datenelement möglicherweise nicht in der lokalen Datenbank, weil es nie vom Client angefragt wurde oder weil es aus der lokalen Datenbank aufgrund einer Cache-Ersetzungsrichtlinie entfernt wurde. In einigen Ausführungsformen, wenn das System erkennt, dass die lokale Datenbank (z. B. der Cache) voll ist, werden zumindest einige der Datenelemente in der lokalen Datenbank (z. B. Cache) gemäß einer Cache-Ersetzungsrichtlinie, die eine von mehreren Optionen sein kann, zum Löschen markiert.
In einigen Ausführungsformen ist die Cache-Ersetzungsrichtlinie eine als letztes verwendete (LRU)-Richtlinie, in der die Datenelemente, die zuletzt verwendet wurden, zuerst aus der lokalen Datenbank gelöscht werden. In einigen Ausführungsformen ist die Cache-Ersetzungsrichtlinie eine am längsten unbenutzte Richtlinie, in der die Datenelemente, auf die am wenigsten häufig zugegriffen wird, zuerst aus der lokalen Datenbank gelöscht werden. In einigen Ausführungsformen wird die Cache-Ersetzungsrichtlinie von einigen anderen Faktoren bestimmt, einschließlich welche Datenelemente die ältesten sind oder die größte Dateigröße haben. In einigen Ausführungsformen wird die Cache-Ersetzungsrichtlinie zufällig bestimmt, d. h. die Datenelemente werden zufällig (also ohne Kriterien zu berücksichtigen, die mit dem Datenelement verbunden sind) aus dem Cache gelöscht. In einigen Ausführungsformen basiert die Cache-Ersetzungsrichtlinie auf einer Kombination von Faktoren, die bestimmen, welche Datenelemente höchstwahrscheinlich nicht von der Webanwendung benötigt werden (z. B. wissen diese, dass eine E-Mail mit bestimmten Merkmalen nur einmal gelesen wird). In einer Ausführungsform wird eine Ersetzungpriorität für jedes Datenelement am Server berechnet und in der lokalen Datenbank gespeichert und Datenelemente in der lokalen Datenbank werden von der Ersetzungsrichtlinie in absteigender Reihenfolge zum Löschen markiert. Zudem sollte verstanden werden, dass jede Cache-Ersetzungsstrategie, die in Hardware-Caches verwendet wird, verwendet werden kann, um zu bestimmen, welche Datenelemente in der lokalen Datenbank zum Löschen markiert sind. In einigen Ausführungsformen entfernt der Client in regelmäßigen Abständen alle zum Löschen markierten Datenelemente aus der lokalen Datenbank. Eine Unterweisung hinsichtlich der Anwendung dieser Ersetzungsstrategien ist für verschiedene Ausführungsformen der vorliegenden Erfindung relevant.
Wenn das Datenelement nicht in der lokalen Datenbank gefunden (710) wird und der Client keine Netzwerkverbindung erkennt (712), wird ein Fehler an die Webanwendung zurückgegeben (714). In einigen Ausführungsformen wird auch ein Fehler an den Benutzer der Webanwendung zurückgegeben (z. B. angezeigt).
Wenn eine Netzwerkverbindung erkannt (716) wird, wird eine Anfrage an das Serversystem gesendet, einschließlich eines eindeutigen Identifiers (z. B. 604-1 in 6B), der eine Kommunikationsstelle verwendet (z. B. eine Webschnittstelle). Das Serversystem empfängt (718) die Anfrage und verwendet in einigen Ausführungsformen den eindeutigen Identifier (z. B. 604-1 in 6B), um ein Datenelement in einer zentralen Datenbank zu suchen (z. B. 120 in 6A), indem der empfangene eindeutige Identifier (z. B. 604-1 in 6A) in einem Serververzeichnis angepasst wird (z. B. 602 in 6A). Das Serversystem ruft (719) das Datenelement (und in einigen Ausführungsformen zusätzliche Informationen zum Datenelement) aus der zentralen Datenbank ab und sendet das Datenelement (und sämtliche zugehörigen Informationen) an den Client.
In einigen Ausführungsformen wird die Anfrage vom Benutzer spezifiziert, wie eine Anfrage zur Anzeige einer nicht komprimierten Darstellung (manchmal auch erweiterte Darstellung genannt) des Datenelements, nachdem eine Auswahl einer komprimierten Darstellung des Datenelements gelöscht wurde. In einem Beispiel (ein E-Mail-Postfach wird angezeigt) beinhaltet das E-Mail-Postfach Header-Informationen (z. B. Absender und Betreff) für eine Vielzahl von E-Mail-Nachrichten oder Gruppen von E-Mail-Nachrichten (z. B. eine oder mehrere zusammengehörende E-Mail-Nachrichten können unter einem Header als einzelne Konversation gruppiert werden). In diesem Beispiel, wenn der Benutzer den Header einer E-Mail-Nachricht oder Konversation auswählt und die Webanwendung die gesamte E-Mail-Nachricht (wenn 10 der Header ein Header für eine einzelne Nachricht ist) oder eine Liste von mindestens einigen E-Mail-Nachrichten (wenn der Header ein Header für eine Konversation von E-Mail-Nachrichten ist) anzeigt.
In einigen Ausführungsformen wird die Anfrage automatisch von der Webanwendung generiert. In einigen Ausführungsformen soll die automatisch generierte Anfrage die Datenelemente, auf die am wahrscheinlichsten vom Benutzer zugegriffen wird, vorher geladen werden. In einem Beispiel wird ein Posteingang mit Header-Informationen (z. B. Absender und Betreff) für eine Vielzahl von E-Mail-Nachrichten oder Gruppen von E-Mail-Nachrichten (z. B. eine oder mehrere zusammengehörende E-Mail-Nachrichten können unter einem Header als einzelne Konversation gruppiert werden) angezeigt. In diesem Beispiel generiert die Webanwendung automatisch eine Anfrage für das Datenelement, das mit jedem der Header in der aktuellen Ansicht des Postfachs verbunden ist. Es sollte verstanden werden, dass die aktuelle Ansicht des Posteingangs jeder der Folgenden sein kann: alle Header im Posteingang (z. B. alle Nachrichten/Konversationen im Posteingang werden angefragt), alle Header, die auf einer aktuellen Seite des Posteingangs beinhalten sind (z. B. alle Nachrichten/Konversationen, durch die ein Benutzer auf dem Bildschirm scrollen kann, werden angefragt), und alle Header, die aktuell angezeigt werden (z. B. nur die Nachrichten/Konversationen, die mit den Headern verbunden sind, die aktuell ohne Scrollen vom Benutzer gesehen werden können, werden angefragt).
Der Client empfängt (708) das Datenelement und führt (720) eine Operation auf dem Datenelement durch. In einigen Ausführungsformen wird das Datenelement durch die Operation nicht aktualisiert (z. B. wird eine E-Mail für einen Benutzer angezeigt). In einigen Ausführungsformen wird das Datenelement durch die Operation aktualisiert (z. B. ist die Operation eine Änderungsoperation, wie das Hinzufügen einer E-Mail-Nachricht zu einer Konversation aus E-Mail-Nachrichten bzw. das Löschen daraus). Wenn die Operation das Datenelement nicht aktualisiert (722), wird der Webanwendungsprozess beendet (723). Wenn die Operation das Datenelement aktualisiert (724), platziert (726) die Webanwendung eine Anfrage zur Durchführung der Operation in der Warteschlange für Schreibanfragen (z. B. 220 in 4). In einigen Ausführungsformen beinhalten die Operationen in der Warteschlange für Schreibanfragen den eindeutigen Identifier aller mit der Operation verbundenen Datenelemente (z. B. wenn die Operation eine Nachricht zu einer entsprechenden Konversation hinzufügen soll, beinhaltet die Operation den eindeutigen Identifier der entsprechenden Konversation). In einigen Ausführungsformen verwendet das Serversystem diesen eindeutigen Identifier, um das in der zentralen Datenbank gespeicherte Datenelement zu identifizieren, auf dem die Operation durchgeführt werden soll (z. B. identifiziert das Serversystem die entsprechende in der zentralen Datenbank gespeicherte Konversation und fügt ihr die Nachricht hinzu).
In einigen Ausführungsformen überprüft (728) die Webanwendung den Status der Netzwerkverbindung, nachdem eine Operation in der Warteschlange für Schreibanfragen platziert wurde. Wenn der Client nicht (732) mit dem Netzwerk verbunden ist, wartet das Clientgerät auf einen Timeout-Zeitraum (734) und überprüft den Status der Netzwerkverbindung erneut (728). In einigen Ausführungsformen überprüft die Webanwendung den Status der Netzwerkverbindung in regelmäßigen Abständen basierend darauf, ob eine Operation zur Warteschlange für Schreibanfragen hinzugefügt wurde (z. B. alle fünf Minuten).
Wenn die Webanwendung erkennt, dass das Clientgerät (736) mit dem Netzwerk verbunden ist, wird die im Clientspeicher verwaltete Warteschlange für Schreibanfragen in den verbundenen Server geleert. In einigen Ausführungsformen ist es wichtig, dass die Warteschlange für Schreibanfragen im nichtflüchtigen Speicher verwaltet wird, sodass die Benutzeranfragen, die gestellt, jedoch noch nicht an das Serversystem gesendet wurden (z. B. weil keine Netzwerkverbindung vorhanden ist), gespeichert, wenn der Webbrowser abstürzt. In einigen Ausführungsformen wird die Warteschlange für Schreibanfragen in der Reihenfolge geleert, in der die Operationen zur Warteschlange für Schreibanfragen hinzugefügt wurden (Beispiel: die älteste Operation wird zuerst an das Serversystem gesendet, gefolgt von der zweitältesten usw.). In einigen Ausführungsformen ist es wichtig, dass die Aktionen in der Warteschlange für Schreibanfragen in der Reihenfolge implementiert werden, in der sie zur Warteschlange hinzugefügt wurden, um sicherzustellen, dass wenn es mehrere Operationen gibt, die das gleiche Datenelement bearbeiten, die Operationen in der richtigen Reihenfolge durchgeführt werden. (z. B. wendet eine erste Operation die Bezeichnung „work” auf eine entsprechende Nachricht/Konversation an und eine zweite Operation markiert alle mit der Bezeichnung „work” verbundenen Nachrichten/Konversationen mit einer Flag, die angibt, dass die Nachricht/Konversation vom Benutzer gelesen wurde).
In einigen Ausführungsformen empfängt (740) das Serversystem die Anfrage von der Webanwendung und antwortet (742) auf die Anfrage (z. B. indem die in der Anfrage angegebene Operation von dem/den eindeutigen Identifier(n), die mit der Anfrage verbunden sind, auf einem oder mehreren Datenelementen durchgeführt wird. In einigen Ausführungsformen werden alle Datenelemente, die von der Operation geändert wurden, in der zentralen Datenbank auf dem Serversystem (744) gespeichert. In einigen Ausführungsformen umfasst die Antwort auf die Anfrage das Senden einer Antwort an die Webanwendung auf dem Client, einschließlich sämtlicher geänderter Datenelemente. Der Client (746) empfängt die Antwort und speichert (748) sämtliche geänderten Datenelemente in der lokalen Datenbank. In einigen Ausführungsformen nimmt der Client Änderungen an den Datenelementen in der lokalen Datenbank durch, da die Operationen aus der Warteschlange für Schreibanfragen geleert werden anstatt dass (oder bevor) eine Antwort vom Server auf die Anfrage zur Durchführung von Operationen empfangen wird.
Die Aufmerksamkeit wird nun auf die 8A–8C gerichtet, in denen Client- und Serverrollen in einem Prozess für das Synchronisieren von Daten zwischen Datenbanken mit einem Prüfsummenaustausch gemäß einigen Ausführungsformen dargestellt werden. In einigen Ausführungsformen beinhaltet der Client eine lokale Datenbank, die mit einer zentralen Datenbank auf einem Serversystem oder einem anderen einzelnen Computergerät, das vom Clientgerät getrennt ist, synchronisiert (z. B. kohärent machen) werden muss. In einem Beispiel ist die Webanwendung eine webbasierte E-Mail-Anwendung, die E-Mail-Nachrichten, Listen mit zugehörigen E-Mail-Nachrichten (z. B. Konversationen) und Listen mit zugehörigen Konversationen (z. B. Thread-Listen) speichert. In diesem Beispiel gewährt die webbasierte E-Mail-Anwendung einem Benutzer Zugang zu Nachrichten/Konversationen in einem E-Mail-Konto. Es ist erstrebenswert, die Webanwendung (z. B. eine Anwendung für den Zugriff auf webbasierte E-Mail) mit einer Serveranwendung synchron zu halten (z. B. ein E-Mail-Server, der alle E-Mails/Konversationen, die mit dem E-Mail-Konto verbunden sind, verwaltet).
Der Prozess beginnt, wenn die Webanwendung Zugriff (802) auf ein Datenelement benötigt, wie eine elektronische Nachricht (z. B. eine E-Mail), eine Konversation (z. B. eine Liste von elektronischen Nachrichten) oder eine Thread-Liste (z. B. eine Liste von Konversationen). In einem Beispiel empfängt die Webanwendung eine Anfrage von einem Benutzer zur Anzeige, zum Senden oder zum Bearbeiten des Datenelement bzw. zur Durchführung einer anderen Operation auf dem Datenelement. Der Client prüft, ob sich das Datenelement in der lokalen Datenbank befindet. Wenn das Datenelement in der lokalen Datenbank gefunden (804) wird, wird es von der lokalen Datenbank abgerufen (806) und die Webwendung empfängt (808) das Datenelement. In einigen Ausführungsformen beinhaltet das aus der lokalen Datenbank abgerufene Datenelement eine erste Prüfsumme, die zuvor in der lokalen Datenbank gespeichert wurde, wie weiter unten ausführlicher beschrieben.
In einigen Ausführungsformen ist die Webwendung eine webbasierte E-Mail-Anwendung (z. B. GMail) mit Offline-Fähigkeiten. Wenn der Client zum Beispiel Zugriff auf eine Netzwerkverbindung hat, verhält sich die Webanwendung genau wie eine normale webbasierte E-Mail-Schnittstelle, an der sich der Benutzer bei einer Webseite anmeldet und E-Mail-Nachrichten abruft und andere Operationen durchführt. In einigen Ausführungsformen hat die webbasierte E-Mail-Anwendung jedoch Offline-Fähigkeiten, die aktiviert werden, indem der Anwendung Zugriff auf eine lokale Datenbank gewährleistet wird, in der einige E-Mail-Nachrichten gespeichert sind, auf die am wahrscheinlichsten von der Webanwendung zugegriffen wird. Wenn der Client keinen Zugriff auf eine Netzwerkverbindung hat und der Benutzer versucht, über den Webbrowser auf das webbasierte E-Mail-Programm zuzugreifen, lässt die Webanwendung (z. B. die webbasierte E-Mail-Anwendung) nach wie vor zu, dass der Benutzer auf die E-Mails zugreift, die in der lokalen Datenbank gespeichert sind, und Operationen auf den in der lokalen Datenbank gespeicherten E-Mails durchführt.
In einigen Ausführungsformen wird der Client im Offline-Modus ausgeführt, einschließlich des Zugriffs auf ein Datenelement, das in der lokalen Datenbank gespeichert ist, des Erkennens einer Operation, die auf dem Datenelement durchgeführt wird, des Schreibens von Informationen, die die Operation in der Warteschlange für Schreibzugriffe neben dem Identifier des Datenelements beschreiben, der Berechnung einer Prüfsumme des aktualisierten Datenelements und des Speicherns der berechneten Prüfsumme in der lokalen Datenbank, wie oben mit Verweis auf die 7A–7B ausführlicher beschrieben. In einigen Ausführungsformen, wenn eine Netzwerkverbindung zwischen der Webanwendung und dem Serversystem erkannt wird, leert der Client die Warteschlange für Schreibanfragen in das Serversystem (z. B. einen webbasierten E-Mail-Server oder ein Serversystem), wo jede an das Serversystem gesendete Anfrage die Operation, einen eindeutigen Identifier eines oder mehrerer von der Operation bearbeiteter Datenelemente und eine Prüfsumme für jedes der Datenelemente beinhaltet.
Die lokale Datenbank wird im nichtflüchtigen Speicher gespeichert, sodass, selbst wenn die Webanwendung abstürzt, sämtliche Operationen, die bis zu diesem Punkt von der Webanwendung in die Warteschlange für Schreibanfragen geschrieben wurden, erhalten bleiben.
Ein Datenelement befindet sich möglicherweise nicht in der lokalen Datenbank, weil es nie vom Client angefragt wurde oder weil es aus der lokalen Datenbank aufgrund einer Cache-Ersetzungsrichtlinie entfernt wurde. In einigen Ausführungsformen, wenn das System erkennt, dass die lokale Datenbank (z. B. der Cache) voll ist, werden zumindest einige der Datenelemente in der lokalen Datenbank (z. B. Cache) gemäß einer Cache-Ersetzungsrichtlinie zum Löschen markiert, wie ausführlicher oben mit Verweis auf die 7A–7B beschrieben.
Wenn das Datenelement nicht in der lokalen Datenbank gefunden (810) wird und der Client keine Netzwerkverbindung erkennt (812), wird ein Fehler an die Webanwendung zurückgegeben (814). in einigen Ausführungsformen wird auch ein Fehler an den Benutzer der Webanwendung zurückgegeben (z. B. angezeigt).
Wenn eine Netzwerkverbindung erkannt (816) wird, wird eine Anfrage an das Serversystem gesendet, einschließlich eines eindeutigen Identifiers (z. B. 604-1 in 6B), der eine Kommunikationsstelle verwendet (z. B. eine Webschnittstelle). Das Serversystem empfängt (818) die Anfrage und verwendet in einigen Ausführungsformen den eindeutigen Identifier (z. B. 604-1 in 6B), um ein Datenelement in einer zentralen Datenbank zu suchen (z. B. 120 in 6A), indem der empfangene eindeutige Identifier (z. B. 604-1 in 6A) in einem Serververzeichnis (z. B. 602 in 6A) angepasst wird. Das Serversystem ruft (820) das Datenelement (und in einigen Ausführungsformen zusätzliche Informationen zum Datenelement) aus der zentralen Datenbank ab und sendet das Datenelement (und sämtliche zugehörigen Informationen) an den Client.
In einigen Ausführungsformen berechnet (820) das Serversystem eine erste Prüfsumme auf dem Datenelement und sendet dieses und die erste Prüfsumme, die mit dem Datenelement verbunden ist, an den Client. Der Client empfängt (808) das Datenelement und die erste Prüfsumme in der lokalen Datenbank und führt eine Operation auf dem Datenelement durch (826) (z. B. zeigt das Datenelement an). In einigen Ausführungsformen umfasst das Durchführen einer Operation auf dem Datenelement das Ändern des Datenelements und der Client berechnet eine Prüfsumme für das geänderte Datenelement und ersetzt die erste Prüfsumme, die in der lokalen Datenbank gespeichert ist, mit der computerberechneten Prüfsumme.
In einigen Ausführungsformen muss (828) die Webanwendung zu einem späteren Zeitpunkt zum zweiten Mal auf das Datenelement zugreifen. Der Client überprüft, ob sich das Datenelement in der lokalen Datenbank befindet. Obwohl das Datenelement zuvor vom Serversystem angefragt und in der lokalen Datenbank gespeichert wurde, ist es möglicherweise nicht länger in der lokalen Datenbank gespeichert. Wenn das Datenelement beispielsweise durch die Implementierung einer Cache-Ersetzungsrichtlinie aus der lokalen Datenbank entfernt wurde, findet der Client das Datenelement nicht in der lokalen Datenbank. Wenn das Datenelement nicht (830) in der lokalen Datenbank gefunden wurde, überprüft der Client, ob es eine Netzwerkverbindung gibt. Ist dies der Fall (816) sendet der Client eine Anfrage an das Serversystem für das Datenelement und empfängt Antworten, wie oben ausführlicher beschrieben. Wenn die Webanwendung beispielsweise eine webbasierte E-Mail-Anwendung ist, muss die Webanwendung das erste Mal, wenn eine E-Mail-Anwendung benötigt wird (z. B zum Anzeigen der Konversation), die Konversation vom webbasierten E-Mail-Server abrufen. In diesem Beispiel berechnet der webbasierte E-Mail-Server eine Prüfsumme auf der Konversation und sendet einen eindeutigen Identifier, der mit der Konversation verbunden ist, und eine Prüfsumme an den Client, die in einer lokalen Datenbank gespeichert sind. Wenn die Webanwendung die Konversation dann zum zweiten Mal benötigt, kann sie einfach den eindeutigen Identifier, der mit der Konversation verbunden ist, und eine Prüfsumme an den Server senden.
Wenn das Datenelement in der lokalen Datenbank gefunden wird (832), ruft der Client das Datenelement von der lokalen Datenbank ab, einschließlich der ersten Prüfsumme (oder der computerberechneten Prüfsumme) und eines eindeutigen Identifiers, der mit dem Datenelement verbunden ist. Der Client sendet (836) eine Anfrage an das Serversystem. In einigen Ausführungsformen beinhaltet diese Anfrage die erste Prüfsumme (oder die computerberechnete Prüfsumme). In einigen Ausführungsformen sendet das Clientgerät die erste Prüfsumme und den eindeutigen Identifier in regelmäßigen Abständen an das Serversystem, wo sie mit der Prüfsumme für das Datenelement auf dem Server verglichen wird. Eine webbasierte E-Mail-Anwendung kann beispielsweise in regelmäßigen Abständen bestätigen, dass eine bestimmte Konversation auf dem neuesten Stand ist, indem sie eine Prüfsumme der Konversation an den webbasierten E-Mail-Server sendet. In diesem Beispiel berechnet der Server eine Prüfsumme der Konversation (wie im Serversystem gespeichert) und, wenn die Prüfsummen nicht übereinstimmen, sendet die Konversation (wie im Serversystem gespeichert) an die webbasierte E-Mail-Anwendung.
In einigen Ausführungsformen hat das Datenelement eine Vielzahl von separaten Komponenten (z. B. ist das Datenelement eine Konversation und die separaten Komponenten sind Nachrichten) und die Anfrage beinhaltet (838) Identifier der Komponenten (z. B. die Anfrage beinhaltet Nachrichten-Identifier, wenn das Datenelement eine Konversation ist, die aus einer Liste von Nachrichten besteht). In einigen Ausführungsformen beinhalten die Identifier der Komponenten alle Komponenten, die mit dem Datenelement auf dem Client verbunden sind (z. B. Nachrichten-Identifier für alle Nachrichten in der Konversation, wie auf dem Client gespeichert).
In einigen Ausführungsformen wird die Anfrage (z. B. 836), die vom Client an das Serversystem gesendet wird, automatisch von der Webanwendung generiert. In einigen Ausführungsformen soll die automatisch generierte Anfrage die Datenelemente, auf die am wahrscheinlichsten vom Benutzer zugegriffen wird, vorher geladen werden. In einem Beispiel wird ein Posteingang mit Header-Informationen (z. B. Absender und Betreff) für eine Vielzahl von E-Mail-Nachrichten oder Gruppen von E-Mail-Nachrichten (z. B. eine oder mehrere zusammengehörende E-Mail-Nachrichten können unter einem Header als einzelne Konversation gruppiert werden), die mit einem Attribut „inbox” verbunden sind, angezeigt. In diesem Beispiel generiert die Webanwendung automatisch eine Anfrage für das Datenelement, das mit jedem der Header in der aktuellen Ansicht des Postfachs verbunden ist. Es sollte verstanden werden, dass die aktuelle Ansicht des Posteingangs jeder der Folgenden sein kann: alle Header im Posteingang (z. B. alle Nachrichten/Konversationen im Posteingang werden angefragt), alle Header, die auf einer aktuellen Seite des Posteingangs beinhalten sind (z. B. alle Nachrichten/Konversationen, durch die ein Benutzer auf dem Bildschirm scrollen kann, werden angefragt), und alle Header, die aktuell angezeigt werden (z. B. nur die Nachrichten/Konversationen, die mit den Headern verbunden sind, die aktuell ohne Scrollen vom Benutzer gesehen werden können, werden angefragt).
In einigen Ausführungsformen können Datenelemente als komprimierte Darstellung (z. B. in komprimierter Form) oder als unkomprimierte Darstellung (z. B. in unkomprimierter Form) angezeigt werden. Datenelemente, die in komprimierter Form angezeigt werden, beinhalten weniger Informationen als Datenelemente, die in unkomprimierter Form angezeigt werden. In einigen Ausführungsformen beinhaltet ein in komprimierter Form angezeigtes Datenelement nur die Header-Information (z. B. Betreff, Sender und Datum/Uhrzeit) über das Datenelement (z. B. die Header-Information zur ersten Nachricht in einer Konversation oder die erste Konversation in einer Thread-Liste). In einigen Ausführungsformen beinhaltet ein in komprimierter Form angezeigtes Datenelement die Anzeige von Header-Informationen für mehrere Komponenten des Datenelements. Wenn das Datenelement beispielsweise eine Thread-Liste ist (z. B. ein Posteingang), beinhaltet das Anzeigen der Thread-Liste in komprimierter Form das Anzeigen von Headers für eine oder mehrere Komponenten (z. B. Konversationen) der Thread-Liste. Wenn das Datenelement beispielsweise eine Konversation ist (z. B. eine Konversation), beinhaltet das Anzeigen der Konversation in komprimierter Form das Anzeigen von Headern für eine oder mehrere Komponenten (z. B. Nachrichten) der Konversation.
In einigen Ausführungsformen hat die Webanwendung ursprünglich nur ausreichend Informationen über ein Datenelement, um die komprimierte Form des Datenelements anzuzeigen (z. B. werden die Header der letzten Konversationen ursprünglich vom Server heruntergeladen). Wenn die Webanwendung Zugriff auf ein bestimmtes Datenelement anfordert (z. B. auf die Thread-Liste, wie ein E-Mail-Postfach, einschließlich einer oder mehrerer Konversationen), wird die komprimierte Form des Datenelements angezeigt (z. B. werden die Header aller Konversationen im Postfach angezeigt). Wenn die Webanwendung zudem den Zugriff auf ein bestimmtes Datenelement anfragt (z. B. ein Web-E-Mail-Postfach), wird das ganze Datenelement heruntergeladen, sodass die Webanwendung die unkomprimierte Form des Datenelements anzeigen kann (z. B. die Header oder Inhalte aller Nachrichten in jeder der Konversationen). In einem anderen Beispiel kann die Webanwendung ursprünglich eine Konversation in komprimierter Form anzeigen (z. B. werden nur die Header von einer oder mehreren E-Mail-Nachrichten in der Konversation angezeigt) und kann die Konversation in unkomprimierter Form anzeigen (z. B. das Anzeigen des kompletten Texts von einer oder mehreren zusätzlichen E-Mail-Nachrichten), nachdem eine Anfrage eines Benutzers zur Anzeige der unkomprimierten Form der Konversation (z. B. eine Anfrage zum Anzeigen des vollständigen Textes einer der Nachrichten in der Konversation).
In einigen Ausführungsformen führt der Client eine Operation (z. B. das Anzeigen des Datenelements) auf dem Datenelement, das in der lokalen Datenbank gespeichert ist, durch (840). In einigen Ausführungsformen wird diese Operation durchgeführt, während auf eine Antwort vom Serversystem gewartet wird.
In einigen Ausführungsformen empfängt (842) das Serversystem die zweite Anfrage für das Datenelement von der Webanwendung, wobei die zweite Anfrage den Identifier des Datenelements und der ersten Prüfsumme beinhaltet. In einigen Ausführungsformen hat das Datenelement eine Vielzahl an diskreten Komponenten (z. B. ist das Datenelement eine Konversation und die diskreten Komponenten sind Nachrichten) und die Anfrage beinhaltet (843) Identifier der Komponenten (z. B. beinhaltet die Anfrage Nachrichten-Identifier, wenn das Datenelement eine Konversation ist, die aus einer Liste an Nachrichten besteht). Als Antwort ruft das Serversystem die Datenelemente von der zentralen Datenbank (844) ab. In einigen Ausführungsformen muss das Serversystem Operationen auf dem Datenelement durchführen (z. B. Operationen, die in der Warteschlange für Schreibanfragen gespeichert und mit der Anfrage gesendet wurden). Das Serversystem führt eine beliebige Operation durch (846), mit der das Datenelement geändert wird (z. B. führt es alle Operationen aus der Warteschlange für Schreibanfragen durch, wie oben ausführlicher mit Verweis auf die 7A–7B erläutert), und berechnet (848) dann eine zweite Prüfsumme des Datenelements.
In einigen Ausführungsformen vergleicht das Serversystem die erste Prüfsumme (oder die vom Client berechnete Prüfsumme) mit der zweiten Prüfsumme. Wenn die Prüfsummen übereinstimmen (850), bestimmt das Serversystem, dass das Datenelement nicht aktualisiert wurde, und sendet (852) eine Antwort an das Clientgerät, in der angegeben wird, dass das Datenelement nicht aktualisiert wurde. In einigen Ausführungsformen ist die Antwort, die angibt, dass das Datenelement nicht aktualisiert wurde, eine leere Antwort (z. B. ist sie im Wesentlichen ähnlich wie eine Antwort, die angibt, dass das Datenelement aktualisiert wurde, abgesehen davon, dass sie keine Daten beinhaltet, um das Datenelement hinzuzufügen oder das Datenelement in der lokalen Datenbank zu ersetzen). Der Client empfängt (854) die Antwort vom Server und da es keine (856) Ersatzdaten gibt, endet der Prozess (857).
Wenn die Prüfsummen nicht übereinstimmen (858), bestimmt das Serversystem, dass das Datenelement aktualisiert wurde, und sendet (860) eine Antwort an den Client, in der angegeben wird, dass das Datenelement aktualisiert wurde. Es sollte verstanden werden, dass es mehrere Strategien für das Aktualisieren des Datenelements in der lokalen Datenbank gibt: gemäß einigen Ausführungsformen, werden entweder 1) alle Daten, die mit dem Datenelement verbunden sind, ersetzt, oder 2) es werden nur die Komponenten des Datenelements ersetzt/zum Datenelement hinzugefügt, die geändert wurden oder neu sind.
In einigen Ausführungsformen beinhaltet die Antwort ein aktualisiertes Datenelement (862) und die zweite Prüfsumme (z. B. wird das gesamte aktualisierte Datenelement an den Client gesendet). Der Client empfängt (854) die Antwort vom Server und da es sich um Ersatzdaten handelt (864) (z. B. eine Ersatzkonversation), werden das Datenelement und die zweite Prüfsumme, die vom Serversystem empfangen wurde, in der lokalen Datenbank gespeichert (866) und ersetzen das alte Datenelement (z. B. in der zuvor gespeicherten Konversation) und die erste Prüfsumme (oder die vom Client berechnete Prüfsumme). Diese Ausführungsform bietet besonders viele Vorteile, wenn eine hohe Netzwerklatenz besteht (z. B. wenn die Kommunikation lange dauert) und die Netzwerkverbindung eine hohe Bandbreite hat (z. B. können große Datenmengen einfach übertragen werden).
In einigen Ausführungsformen wird das Datenelement erneut in der Webanwendung angezeigt (867), nachdem das aktualisierte Datenelement (oder die Datenelementkomponenten) vom Serversystem empfangen wurden. Beispielsweise kann ein Benutzer eine Anfrage zur Anzeige einer Konversation (z. B. eine Liste von E-Mail-Nachrichten) in einem E-Mail-Postfach senden. In diesem Beispiel zeigt die Webanwendung ursprünglich die Kopie der Konversation an, die in der lokalen Datenbank gespeichert ist. In Zusammenhang mit dem Anzeigen der lokal gespeicherten Konversation sendet die Webanwendung gleichzeitig (oder fast gleichzeitig) eine Anfrage an das Serversystem, einschließlich einer Prüfsumme einer lokal gespeicherten Konversation. Wenn das Serversystem in diesem Beispiel eine Ersatzkonversation (Datenelement aktualisieren) oder zusätzliche E-Mail-Nachrichten für die Konversation (neue/aktualisierte Komponenten) sendet, zeigt die Webanwendung die aktualisierte Konversation (oder die neuen E-Mails in der Konversation) erneut an. In einigen Ausführungsformen wird das Datenelement automatisch aktualisiert (z. B. automatisch erneut angezeigt). In einigen Ausführungsformen wird eine Nachricht angezeigt, die angibt, dass das angezeigte Datenelement nicht auf dem neuesten Stand ist (z. B. dass ein aktualisiertes Datenelement verfügbar ist). Die Nachricht kann beispielsweise wie folgt lauten: „Neue Nachrichten wurden für diese Konversation empfangen. Möchten Sie sie anzeigen?” In einigen Ausführungsformen wird ein aktualisiertes Datenelement angezeigt (z. B. wird das Datenelement erneut angezeigt), wenn der Benutzer die Anzeige des aktualisierten Datenelements anfragt (z. B. indem die Schaltfläche „Neu laden” oder „Neue Nachrichten anzeigen” ausgewählt wird).
In einigen Ausführungsformen, in denen die Anfrage vom Client Komponenten-Identifier beinhaltet (z. B. Nachrichten-Identifier), beinhaltet (868) die Antwort eine oder mehrere neue Komponenten. In einigen Ausführungsformen ist eine neue Komponente eines Datenelements eine Komponente mit einem Komponenten-Identifier, der nicht mit einem der Komponenten des alten Datenelements übereinstimmt (z. B wurde eine neue E-Mail zur Konversation hinzugefügt). In einigen Ausführungsformen ist eine neue Komponente eine aktualisierte Komponente, die eine andere Prüfsumme hat als die alte Komponente mit dem gleichen Komponenten-Identifier (z. B. wurde eine E-Mail in der Konversation geändert). Neue Komponenten sind Komponenten, die mit dem Datenelement, aber nicht mit einem der in der Anfrage enthaltenen Komponenten-Identifier verbunden sind.
Wenn das Datenelement beispielsweise eine Konversation ist und die Komponenten E-Mail-Nachrichten in einer Konversation sind, sendet der Client eine Anfrage an den Server, einschließlich des Identifiers der Konversation und eine Liste an E-Mail-Nachrichten (z. B. eine erste E-Mail, eine zweite E-Mail und eine dritte E-Mail), die Komponenten der Konversation sind. In diesem Beispiel ruft der Server die Konversation von der zentralen Datenbank ab und benachrichtigt die Nachrichten-Identifier, die in der Konversation beinhalten sind (z. B. eine erste E-Mail, eine zweite E-Mail und eine dritte E-Mail, eine vierte E-Mail und eine fünfte E-Mail), und sendet nur die neuen E-Mail-Nachrichten (z. B. die vierte E-Mail und die fünfte E-Mail) an das Clientgerät in der Antwort. Der Client empfängt (854) die Antwort vom Server und da Ersatzdaten vorhanden sind (864), werden die neuen Komponenten des Datenelements in der lokalen Datenbank gespeichert (866) und sind mit dem Datenelement in der lokalen Datenbank verbunden. Zudem ersetzt die zweite Prüfsumme die erste Prüfsumme (oder die vom Client berechnete Prüfsumme) in der lokalen Datenbank. Diese Ausführungsform bietet besonders viele Vorteile, wenn eine hohe Netzwerklatenz besteht (z. B. wenn die Kommunikation lange dauert) und die Netzwerkverbindung eine niedrigere Bandbreite hat (z. B. gibt es einige Beschränkungen, wie viele Daten übertragen werden können, es ist also von Vorteil, nur einige Komponenten des Datenelements senden, wenn nur einige Komponenten notwendig sind, um das in der lokalen Datenbank gespeicherte Datenelement mit dem Datenelement zu synchronisieren, das in der zentralen Datenbank gespeichert ist).
In einigen Ausführungsformen, wo die Anfrage vom Client keine Komponenten-Identifier beinhaltet), beinhaltet (870) die Antwort eine Anfrage von den Komponenten-Identifiern im Datenelement. In dieser Ausführungsform empfängt (872) der Client die Anfrage für Komponenten-Identifier, die mit dem Datenelement verbunden sind, (z. B. Nachrichten-Identifier, die mit einer Konversation verbunden sind, oder Thread-Identifier, die mit einer Thread-Liste verbunden sind). Der Client ruft (874) die Komponenten-Identifier, die mit dem Datenelement verbunden sind, von der lokalen Datenbank ab und sendet (876) die Komponenten-Identifier (zusammen mit dem verbundenen eindeutigen Identifier für das Datenelement) an das Serversystem. Das Serversystem empfängt die Anfrage und ruft das Datenelement, das vom eindeutigen Identifier angegeben wurde, von der zentralen Datenbank ab (878).
Das Serversystem vergleicht (880) die Komponenten-Identifier, die mit dem Datenelement in der zentralen Datenbank verbunden sind, mit den Komponenten-Identifiern, die vom Clientgerät an das Serversystem gesendet wurden. Durch den Vergleich der beiden Sätze an Komponenten-Identifiern bestimmt (882) das Serversystem, welche Komponenten, falls vorhanden, des Datenelements in der zentralen Datenbank neu sind. In einem Beispiel ist das Datenelement eine Konversation mit drei Nachrichten (z. B. Komponenten), in der die Client-Version der Konversation nur die ersten beiden Nachrichten beinhaltet, während die Serversystem-Version der Konversation alle drei Nachrichten beinhaltet. In diesem Beispiel sendet das Serversystem Nachrichten-Identifier für eine erste Nachricht und eine zweite Nachricht in der Konversation. In diesem Beispiel ruft das Serversystem die Konversation von der zentralen Datenbank ab, identifiziert die erste Nachricht, die zweite Nachricht und eine dritte Nachricht. In diesem Beispiel vergleicht das Serversystem die Nachrichten-Identifier vom Client mit den Nachrichten, die von der zentralen Datenbank abgerufen wurden, und bestimmt, dass die dritte Nachricht eine neue Nachricht ist (z. B. eine neue Komponente).
In einigen Ausführungsformen, nachdem bestimmt wurde, dass es eine oder mehrere neue Komponenten im Datenelement gibt, sendet (884) das Serversystem eine oder mehrere neue Komponenten an den Client mit der zweiten Prüfsumme. Der Client empfängt (886) die eine oder mehrere neue Komponente(n) und die zweite Prüfsumme und speichert (888) die eine oder mehrere neue(n) Komponenten und die zweite Prüfsumme in der lokalen Datenbank. Es sollte beachtet werden, dass während diese Ausführungsform mehrere Trips vor und zurück beinhaltet, die Trips insgesamt eine kleinere Menge an Daten beinhaltet, die zwischen dem Client und dem Server übertragen werden. Daher ist diese Ausführungsform besonders von Vorteil, wenn die Netzwerklatenz niedrig ist (z. B. wenn die Kommunikation nicht lange dauert) und die Netzwerkverbindung eine geringe Bandbreite hat (z. B. gibt es Beschränkungen, wie viele Daten übertragen werden können, weswegen es vorteilhaft ist, nur die Komponenten des Datenelements zu senden, die gesendet werden müssen).
In einigen Ausführungsformen wird eine Kombination aus Methoden (z. B. Aktualisieren des gesamten Datenelements, Senden von Komponenten oder Senden einer Anfrage für eine Liste der Komponenten und anschließendes Senden der Komponenten) für das Aktualisieren der Datenelemente verwendet. Das Clientgerät bestimmt die Bandbreite der Verbindung zwischen dem Clientgerät und dem Serversystem und/oder der Latenz der Verbindung und bestimmt die beste zu verwendende Methode basierend auf Berücksichtigungen der Bandbreitenverfügbarkeit oder Verzögerung aufgrund der Netzwerklatenz. In einigen Ausführungsformen bestimmt das Serversystem die Bandbreite der Verbindung zwischen dem Clientgerät und dem Serversystem und/oder der Latenz der Verbindung und bestimmt die beste zu verwendende Methode basierend auf Berücksichtigungen der Bandbreitenverfügbarkeit oder Verzögerung aufgrund von Netzwerklatenz.
Jede der hier beschriebenen Methoden kann von Anweisungen festgelegt werden, die in einem computerlesbaren Speichermedium gespeichert sind und von einem oder mehreren Prozessoren eines oder mehrerer Serversysteme 106 oder Clientgeräte 102 ausgeführt werden. Jede der in den 7A–7B und 8A–8C gespeicherten Operationen deckt sich möglicherweise mit Anweisungen, die in einem Computerspeicher oder computerlesbaren Speichermedium gespeichert sind.
Die vorstehende Beschreibung wurde zum Zweck der Erklärung unter Bezugnahme auf spezifische Ausführungsformen beschrieben. Jedoch sollen die oben stehenden veranschaulichenden Erörterungen nicht erschöpfend sein oder die Erfindung auf die genauen offenbarten Formen beschränken. Angesichts der oben stehenden Lehren sind viele Modifikationen und Abwandlungen möglich. Die Ausführungsformen wurden gewählt und beschrieben, um die Prinzipien der Erfindungen und ihre praktischen Anwendungen zu beschreiben, um es dadurch anderen Fachleuten zu ermöglichen, die Erfindungen und verschiedenen Ausführungsformen mit verschiedenen Modifizierungen zu nutzen, die für die besondere, erwähnte Nutzung geeignet sind.
Die folgenden Abschnitte beschreiben bevorzugte Aspekte der Erfindung.

A1. Computersystem für das Betreiben einer Webanwendung mit Offline-Fähigkeiten, umfassend: ein Clientgerät mit einem Computerprozessor und Computerspeicher; einen Webbrowser, der auf dem Clientgerät ausgeführt wird; eine lokalen Webanwendung, die so konfiguriert ist, dass sie im Webbrowser ausgeführt wird; eine Webschnittstelle, die so konfiguriert ist, dass sie Kommunikationen zwischen der lokalen Webanwendung und einem Serversystem, das mit der Webanwendung verbunden ist, verwalten; eine im Speicher verwaltete Warteschlange für Schreibanfragen; eine persistente lokalen Datenbank, die im Speicher gepflegt wird, der mehrere Datenelemente beinhaltet, die jeweils mit einem Identifier verbunden sind, der ermöglicht, dass jedes entsprechende Datenelement eindeutig auf dem Clientgerät oder einem Serversystem identifiziert wird, worin gilt: wenn eine Webanwendung eine Operation auf einem Datenelement durchführen muss, die Webanwendung eine Datenbankanfrage ausgibt, um zu bestimmen, ob sich das Datenelement in der lokalen Datenbank befindet; wenn sich das Datenelement nicht in der lokalen Datenbank befindet, die Webanwendung die Datenanfrage über die Webschnittstelle an das Serversystem ausgibt; wenn sich das Datenelement in der lokalen Datenbank befindet und die Operation das Aktualisieren des Datenelements umfasst, die Webwendung die Operation auf dem Datenelement durchführt, das in der Datenbank gespeichert ist, und Informationen, die die Operation beschreiben, zusammen mit dem Identifier des Datenelements in die Warteschlange für Schreibanfragen schreibt; wenn eine Netzwerkverbindung zwischen dem Clientgerät und dem Serversystem besteht, die Webschnittstelle die Warteschlange für Schreibanfragen in das Serversystem leert.
A2. Computersystem nach der Klausel A1, worin die lokale Datenbank in einem nichtflüchtigen Speicher gespeichert ist.
A3. Computersystem nach der Klausel A1 oder Klausel A2, worin die Webanwendung eine webbasierte E-Mail-Anwendung mit Offline-Fähigkeiten ist.
A4. Computersystem nach den Klauseln A1, A2 oder A3, worin die Datenelemente Thread-Listen oder Konversationen in der E-Mail-Anwendung sind.
A5. Computersystem nach den Klauseln A1, A2, A3 oder A4, worin, wenn das Computersystem erkennt, dass der Cache voll ist, mindestens einige der Datenelemente im Cache gemäß einer Cache-Ersetzungsrichtlinie zum Löschen markiert sind.
A6. Computersystem nach den Klauseln A1, A2, A3, A4 oder A5, worin das Leeren der Warteschlange für Schreibanfragen das Senden von Operationen an das Serversystem umfasst, in der Reihenfolge, in der sie in der Warteschlange für Schreibanfragen gespeichert wurden.
A7. Computerimplementiertes Verfahren für das Betreiben einer Webanwendung mit Offline-Fähigkeiten an einem Clientgerät mit einem Computerprozessor und einem Computerspeicher, umfassend: das Ausführen eines Webbrowsers auf dem Clientgerät, das Ausführen einer lokalen Webanwendung, die so konfiguriert ist, dass sie im Webbrowser ausgeführt wird, dem Verwalten der Kommunikationen zwischen der lokalen Webanwendung und einem Serversystem, das mit der Webanwendung mit einer Webschnittstelle verbunden ist; das Verwalten einer Warteschlange für Schreibanfragen im Speicher; das Verwalten einer persistenten lokalen Datenbank im Speicher, der mehrere Datenelemente beinhaltet, die jeweils mit einem Identifier verbunden sind, der zulässt, dass jedes entsprechende Datenelement eindeutig auf dem Clientgerät und dem Serversystem identifiziert, worin gilt: Wenn die Webanwendung eine Operation auf einem Datenelement durchführen muss, die Webanwendung eine Datenbankanfrage ausgibt, um zu bestimmen, ob sich das Datenelement in der lokalen Datenbank befindet; wenn sich das Datenelement nicht in der lokalen Datenbank befindet, die Webanwendung die Datenanfrage über die Webschnittstelle an das Serversystem ausgibt; wenn sich das Datenelement in der lokalen Datenbank befindet und die Operation das Aktualisieren des Datenelements umfasst, die Webanwendung die Operation auf dem in der Datenbank gespeicherten Datenelement ausführt und Informationen, die die Operation kennzeichnen, zusammen mit dem Identifier des Datenelements in die Warteschlange für Schreibanfragen schreibt; wenn eine Netzwerkverbindung zwischen dem Clientgerät und dem Serversystem besteht, die Webschnittstelle die Warteschlange für Schreibanfragen in das Serversystem leert.
A8. Die computerimplementierte Methode der Klausel A7, worin die lokale Datenbank im nichTflüchtigen Speicher gespeichert ist.
A9. Computerimplementiertes Verfahren nach den Klauseln A7 oder A8, worin die Webanwendung eine webbasierte E-Mail-Anwendung mit Offline-Fähigkeiten ist.
A10. Computerimplementiertes Verfahren nach den Klauseln A7, A8 oder A9, worin die Datenelemente Thread-Listen oder Konversationen in der E-Mail-Anwendung sind.
A11. Computerimplementiertes Verfahren nach den Klauseln A7, A8, A9 oder A10, worin, wenn das Computersystem erkennt, dass der Cache voll ist, mindestens einige der Datenelemente im Cache gemäß einer Cache-Ersetzungsrichtlinie zum Löschen markiert sind.
A12. Computerimplementiertes Verfahren nach den Klauseln A7, A8, A9, A10 oder A11, worin das Leeren der Warteschlange für Schreibanfragen das Senden der Operationen in der Warteschlange für Schreibanfragen an das Serversystem umfasst, in der Reihenfolge, in der sie in der Warteschlange für Schreibanfragen gespeichert wurden.
A13. Computerlesbares Speichermedium, das ein oder mehrere Programme für das Ausführen durch einen oder mehrere Prozessoren eines Clientgeräts speichert, wobei das eine oder die mehreren Programme Anweisungen für Folgendes umfassen: das Ausführen eines Webbrowsers auf dem Clientgerät, das Ausführen einer lokalen Webanwendung im Webbrowser, das Verwalten von Kommunikationen zwischen der lokalen Webanwendung und einem Serversystem, das mit der Webanwendung mit einer Webschnittstelle verbunden ist, das Verwalten einer Warteschlange für Schreibanfragen im Speicher, das Verwalten einer persistenten lokalen Datenbank im Speicher, der mehrere Datenelemente beinhaltet, die jeweils mit einem Identifier verbunden sind, der zulässt, dass jedes entsprechende Datenelement eindeutig auf dem Clientgerät und dem Serversystem identifiziert, worin: Wenn die Webanwendung eine Operation auf einem Datenelement durchführen muss, gibt die Webanwendung eine Datenbankanfrage aus, um zu bestimmen, ob sich das Datenelement in der lokalen Datenbank befindet. Wenn sich das Datenelement nicht in der lokalen Datenbank befindet, gibt die Webanwendung die Datenanfrage über die Webschnittstelle an das Serversystem aus. Wenn sich das Datenelement in der lokalen Datenbank befindet und die Operation das Aktualisieren des Datenelements umfasst, führt die Webanwendung die Operation auf dem in der Datenbank gespeicherten Datenelement aus und schreibt Informationen, die die Operation kennzeichnen, in die Warteschlange für Schreibanfragen, zusammen mit dem Identifier des Datenelements. Wenn eine Netzwerkverbindung zwischen dem Clientgerät und dem Serversystem besteht, leert die Webschnittstelle die Warteschlange für Schreibanfragen in das Serversystem.
A14. Computerlesbares Speichermedium nach den Klausel A13, worin die lokale Datenbank im nichtflüchtigen Speicher gespeichert wird.
A15. Computerlesbares Speichermedium nach den Klauseln A13 und A14, worin die Webanwendung eine webbasierte E-Mail-Anwendung mit Offline-Fähigkeiten ist.
A16. Computerlesbare Speichermedium nach den Klauseln A13, A14 und A15, worin die Datenelemente Thread-Listen oder Konversationen in der E-Mail-Anwendung sind.
A17. Computerlesbares Speichermedium nach den Klauseln A13, A14, A15 oder A16, worin, wenn das Computersystem erkennt, dass der Cache voll ist, mindestens einige der Datenelemente im Cache gemäß einer Cache-Ersetzungsrichtlinie zum Löschen markiert sind.
A18. Computerlesbares Speichermedium nach den Klauseln A13, A14, A15, A16 oder A17, worin das Leeren der Warteschlange für Schreibanfragen das Senden der Operationen in der Warteschlange für Schreibanfragen an das Serversystem umfasst, in der Reihenfolge, in der sie in der Warteschlange für Schreibanfragen gespeichert wurden.

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 2005/0222985 A1 [0058]

Claims

Serversystem, Folgendes umfassend: einen Prozessor oder mehrere Prozessoren; Speicher; und ein oder mehrere Programme, worin ein oder mehrere Programme im Speicher für die Ausführung von einem oder mehreren Prozessoren gespeichert sind. Das bzw. die Programme beinhalten Anweisungen für Folgendes: das Empfangen einer ersten Anfrage für ein Datenelement von einem Clientgerät, worin die erste Anfrage einen Identifier des Datenelements beinhaltet; als Antwort auf die erste Anfrage: das Berechnen einer ersten Prüfsumme des Datenelements; und das Senden des Datenelements und der ersten Prüfsumme an das Clientgerät, für das Speichern in einer lokalen Datenbank am Clientgerät, sodass das Clientgerät keine Prüfsumme des Datenelements berechnet; das Empfangen einer zweiten Anfrage für das Datenelement vom Clientgerät, worin die zweite Anfrage den Identifier des Datenelements und die erste Prüfsumme, die zuvor vom Serversystem berechnet wurde, beinhaltet; als Antwort auf die zweite Anfrage: das Berechnen einer zweiten Prüfsumme des Datenelements und das Vergleichen der ersten Prüfsumme mit der zweiten Prüfsumme; das Bestimmen, dass das Datenelement basierend auf mindestens teilweise dem Vergleich der ersten mit der zweiten Prüfsumme aktualisiert wurde; gemäß der Bestimmung, dass das Datenelement aktualisiert wurde: das Senden einer Antwort an das Clientgerät, in der angegeben wird, dass das Datenelement aktualisiert wurde, die Antwort einschließlich einer Anfrage für eine erste Vielzahl an Nachrichten-Identifiern, die jeweils zu einer Komponente des Datenelements, das in der lokalen Datenbank gespeichert ist, gehören; das Empfangen einer Kommunikation vom Clientgerät, worin die Kommunikation die erste Vielzahl der Nachrichten-Identifier umfasst; als Antwort auf die zweite Anfrage: Vergleichen der ersten Gruppe von Nachrichten-Identifiern, die vom Clientgerät empfangen wurden, mit einer zweiten Vielzahl von Nachrichten-Identifiern, die mit einer zweiten Gruppe von Komponenten des Datenelements verbunden sind; das Bestimmen eines entsprechenden Nachrichten-Identifiers in der zweiten Vielzahl der Nachrichten-Identifier, der nicht in der ersten Vielzahl von Nachrichten-Identifiern vorhanden ist: und als Antwort auf das Bestimmen des entsprechenden Nachrichten-Identifiers: das Senden der entsprechenden Komponente, die mit dem entsprechenden Identifier verbunden ist, und der zweiten Prüfsumme an das Clientgerät.
Serversystem nach Anspruch 1, worin die Antwort angibt, dass das Datenelement aktualisiert wurde, beinhaltet das aktuelle Datenelement und die zweite Prüfsumme.
Serversystem nach Anspruch 1 und 2, worin das Clientgerät so konfiguriert ist, dass es im Offline-Modus ausgeführt wird, worin das Ausführen im Offline-Modus Folgendes umfasst: das Zugreifen auf das Datenelement von der lokalen Datenbank; Das Erkennen einer Operation, die auf dem Datenelement durchgeführt wird; das Schreiben von Informationen, die die Operation in einer Warteschlange für Schreibzugriffe neben dem Identifier des Datenelements beschreiben; das Erkennen einer Netzwerkverbindung zwischen dem Clientgerät und dem Serversystem; und als Antwort auf das Erkennen der Netzwerkverbindung: das Leeren der Warteschlange für Schreibanfragen in das Serversystem.
Serversystem nach Anspruch 3, worin das eine oder die mehreren Programme Anweisungen für das Durchführen von Operationen von der Warteschlange für Schreibanfragen des Clientgeräts vor der Berechnung der zweiten Prüfsumme des Datenelements beinhalten.
Serversystem nach irgendeinem der Ansprüche 1–4, worin das eine oder die mehreren Programme Anweisungen beinhalten für Folgendes: als Antwort auf das Bestimmen, dass das Datenelement nicht aktualisiert wurde: das Senden einer Nachricht an das Clientgerät, die angibt, dass das Datenelement nicht aktualisiert wurde.
Serversystem nach irgendeinem der Ansprüchen 1–5, worin das Clientgerät eine mobile E-Mail-Anwendung ist und das Datenelement eine der Listen beinhaltet, die Folgendes umfasst: eine Konversation, die eine Liste der E-Mail-Nachrichten und eine Thread-Liste beinhaltet, die eine Liste der Konversationen beinhaltet.
Computerlesbares Speichermedium, das ein oder mehrere Programme für die Ausführung von einem oder mehreren Prozessoren auf einem Clientgerät speichert, wobei das eine oder die mehreren Programme Anweisungen umfassen für Folgendes: das Empfangen einer ersten Anfrage für ein Datenelement aus einem Clientgerät, wobei die erste Anfrage einen Identifier des Datenelements beinhaltet: als Antwort auf die erste Anfrage: das Berechnen einer ersten Prüfsumme des Datenelements; und das Senden des Datenelements und der ersten Prüfsumme an das Clientgerät, für das Speichern in einer lokalen Datenbank am Clientgerät, sodass das Clientgerät keine Prüfsumme des Datenelements berechnet; das Empfangen einer zweiten Anfrage für das Datenelement vom Clientgerät, worin die zweite Anfrage den Identifier des Datenelements und die zweite Prüfsumme, die zuvor vom Serversystem berechnet wurde, beinhaltet; als Antwort auf die zweite Anfrage: das Berechnen einer zweiten Prüfsumme des Datenelements und das Vergleichen der ersten Prüfsumme mit der zweiten Prüfsumme; das Bestimmen, dass das Datenelement basierend auf zumindest teilweise dem Vergleich der ersten Prüfsumme mit der zweiten aktualisiert wurde; gemäß der Bestimmung, dass das Datenelement aktualisiert wurde: das Senden einer Antwort an das Clientgerät, in der angegeben wird, dass das Datenelement aktualisiert wurde, wobei die Antwort eine Anfrage für eine erste Vielzahl von Nachrichten-Identifiern beinhaltet, die jeweils einer Komponente des in der lokalen Datenbank gespeicherten Datenelements entsprechen; das Empfangen einer Kommunikation vom Clientgerät, worin die Kommunikation die erste Vielzahl von Nachrichten-Identifier beinhaltet; als Antwort auf die zweite Anfrage: Vergleichen der ersten Vielzahl von Nachrichten-Identifiern, die vom Clientgerät empfangen wurden, mit einer zweiten Vielzahl von Nachrichten-Identifiern, die mit einer zweiten Vielzahl von Komponenten des Datenelements verbunden sind; das Bestimmen eines entsprechenden Nachrichten-Identifiers in der zweiten Vielzahl von Nachrichten-Identifier, der nicht in der ersten Vielzahl von Nachrichten-Identifier ist, und als Antwort auf das Bestimmen des entsprechenden Nachrichten-Identifiers: das Senden der entsprechenden Komponente, die mit dem entsprechenden Identifier verbunden ist, und der zweiten Prüfsumme an das Clientgerät.
Computerlesbares Speichermedium aus Anspruch 7, worin die Antwort angibt, dass das Datenelement aktualisiert wurde, beinhaltet das aktualisierte Datenelement und die zweite Prüfsumme.
Computerlesbares Speichermedium nach den Ansprüchen 7 oder 8, worin das Clientgerät so konfiguriert ist, dass es im Offline-Modus betrieben wird, worin das Betreiben im Offline-Modus Folgendes umfasst: das Zugreifen auf das Datenelement von der lokalen Datenbank; Erkennen einer auf dem Datenelement durchgeführten Operation; das Schreiben von Informationen, die die Operation beschreiben, in eine Warteschlange für Schreibanfragen zusammen mit dem Identifier des Datenelements; das Erkennen einer Netzwerkverbindung zwischen dem Clientgerät und dem Serversystem; und als Antwort auf das Erkennen der Netzwerkverbindung: das Leeren der Warteschlange für Schreibanfragen in das Serversystem.