DE102018002899A1

DE102018002899A1 - Verwalten von Digitalassets, die als Komponenten und gepackte Dateien gespeichert sind

Info

Publication number: DE102018002899A1
Application number: DE102018002899.3A
Authority: DE
Inventors: Stanley J. Switzer; Roey Horns; Oliver I. Goldman; Michael Vitrano; Julian R. Wixson
Original assignee: Adobe Systems Inc
Current assignee: Adobe Inc
Priority date: 2017-06-22
Filing date: 2018-04-10
Publication date: 2018-12-27
Also published as: US20230244404A1; AU2018202512A1; US20180373434A1; GB201806362D0; AU2018202512B2; US11635908B2; GB2564923A; CN109117425A; GB2564923B

Abstract

Die vorliegende Offenbarung betrifft ein Digitalassetsynchronisierungssystem, das eine verbesserte Digitalassetverwaltung und Synchronisierung eines Digitalassets, das entweder in einer Komponentendatenbank oder einer gepackten Datei gespeichert ist, ermöglicht. Das Digitalassetsynchronisierungssystem ermöglicht beispielsweise, dass ein Satz von Komponenten, die ein Digitalasset bilden, als eine einzige gepackte Datei erscheint, während die Vorteile dessen, dass das Digitalasset aus Komponenten besteht, erhalten bleiben. Auf diese Weise bildet das Digitalassetsynchronisierungssystem eine Brücke zwischen einem Digitalasset, das in einem gepackten Dateiformat gespeichert ist, und herkömmlichen Dateiformaten. Zusätzlich ermöglicht das Digitalassetsynchronisierungssystem eine Digitalassetverwaltung und eine verbesserte Synchronisierung zwischen einer Clientvorrichtung und einem Cloudspeichersystem.

Description

Hintergrund
Mit dem Aufkommen von Computern und Computertechnologien gehen zahlreiche Vorteile einher. Einige dieser Vorteile betreffen die Fähigkeit, dass der Einzelne von verschiedenen Rechenvorrichtungen aus, die er nutzt, auf Dateien zugreifen kann. Verschiedene Dateiverwaltungssysteme ermöglichen beispielsweise, dass der Einzelne oder eine Gruppe von Einzelnen Dateien über mehrere Clientvorrichtungen hinweg synchronisieren und zudem auf ihre Dateien in der Cloud (beispielsweise über das Internet) zugreifen. Ungeachtet dieser und anderer Vorteile bringen herkömmliche Dateiverwaltungssysteme jedoch auch Nachteile mit sich.
Es werden nunmehr demonstrationshalber einige Nachteile aufgeführt. Einige herkömmliche Dateiverwaltungssysteme ermöglichen, dass der Einzelne Dateien zwischen einer Rechenvorrichtung und einem Remote-Server synchronisiert. Jedes Mal, wenn eine Änderung an einer Datei erfolgt, synchronisieren einige herkömmliche Dateiverwaltungssysteme jedoch die gesamte modifizierte Datei erneut. Nimmt ein Nutzer beispielsweise eine unbedeutende Änderung an einer großen Datei vor, so synchronisieren herkömmliche Dateiverwaltungssysteme die gesamte Datei erneut. Auf gleiche Weise lädt immer dann, wenn eine Änderung an einer Datei auf dem Remote-Server detektiert wird, die Rechenvorrichtung eine vollständige Kopie der modifizierten Datei herunter, was zu einer ineffizienten Nutzung der Bandbreite und Speicherressourcen führt. Synchronisieren zusätzliche Vorrichtungen die Datei, so verschärft sich dieses Problem weiter, da das Dateiverwaltungssystem dann eine vollständige Kopie der Datei an jede Vorrichtung überträgt.
Bei einem weiteren exemplarischen Nachteil beschränken herkömmliche Dateiverwaltungssysteme oftmals die Fähigkeit mehrerer Vorrichtungen oder Anwendungen, gleichzeitig auf eine Datei zuzugreifen, und zwar insbesondere dann, wenn Bearbeitungen gleichzeitig durchgeführt werden. Herkömmliche Dateiverwaltungssysteme verhindern beispielsweise oftmals das Modifizieren einer Datei durch eine Vorrichtung/Anwendung, wenn auch von einer anderen Vorrichtung/Anwendung auf die Datei zugegriffen wird. Insbesondere beschränken einige herkömmliche Dateiverwaltungssysteme den Lese-Schreib-Zugriff auf eine Vorrichtung/Anwendung und ermöglichen anderen Vorrichtungen lediglich einen Nur-Lese-Zugriff.
Entsprechend einem weiteren Nachteil ermöglichen viele herkömmliche Dateiverwaltungssysteme eine schlechte Konfliktbehebung zwischen mehreren Versionen derselben Datei. Sind beispielsweise verschiedene Versionen derselben Datei vorhanden, so erstellen herkömmliche Dateiverwaltungssysteme oftmals vollständige Duplikate der Datei. Das Erstellen eines vollständigen Duplikates der Datei erfordert nicht nur zusätzliche Speicherressourcen, sondern es erzeugen diese mehreren Kopien der Datei auch oftmals Konflikte. So bleibt beispielsweise dem Einzelnen überlassen herauszufinden, welche Kopien welche Modifikationen enthalten, ob Modifikationen zwischen verschiedenen Kopien zusammenzuführen sind und/oder ob eine oder mehrere Kopien als duplizierte oder veraltete Version zu löschen sind. Darüber hinaus richten diese Dateikopien auf den Vorrichtungen ein Durcheinander an (es beginnen beispielsweise mehrere Kopien ein und derselben Datei, in Ordnern und Verzeichnissen zu erscheinen). Im Ergebnis tritt beim Einzelnen Verwirrung darüber auf, was er mit jeder Dateikopie anfangen soll, was in einigen Fällen zum unrichtigen Entfernen einer Datei führt, die korrekte Überarbeitungen beinhaltet.
Diese und zusätzliche Probleme und Fragestellungen sind bei herkömmlichen Dateiverwaltungssystemen vorhanden. Es besteht die Notwendigkeit einer Verbesserung auf dem Gebiet der Dateiverwaltung innerhalb einer Rechenvorrichtung wie auch zwischen Rechenvorrichtungen.
Kurze Zusammenfassung
Eine oder mehrere Ausführungsformen der vorliegenden Offenbarung beinhalten Systeme und Verfahren, die eine verbesserte Digitalassetverwaltung und Synchronisierung bei einem Digitalasset, das entweder in einer Komponentendatenbank oder einer gepackten Datei gespeichert ist, bereitstellen. Insbesondere verwalten die Systeme und Verfahren bei einer oder mehreren Ausführungsformen Digitalassets durch Separieren eines jeden Digitalassets (eines Digitalbildes, einer Datei und dergleichen) in intrinsische Komponenten, die das Digitalasset bilden (Schichten, Seiten und dergleichen mehr) und Speichern der Komponenten als separate individuelle Dateien. Eine Komponente beinhaltet Content innerhalb einer definierten Grenze eines Digitalassets und ist modifizierbar, ohne andere Komponenten des Digitalassets, so beispielsweise eine Schicht eines Bildes oder eine Seite eines Dokumentes, zu beeinflussen. Die komponentenbasierte Verwaltung der Digitalassets ermöglicht, dass die Verfahren und Systeme die Komponenten einzeln anstelle des gesamten Digitalassets speichern und synchronisieren, wenn Änderungen an dem Digitalasset vorgenommen werden.
Des Weiteren ermöglichen die Systeme und Verfahren, dass ein Satz von Komponenten, der ein Digitalasset bildet, gegenüber einem Nutzer als eine einzige Datei, die gepackte Datei genannt wird, erscheint. Auf diese Weise verbessern die Systeme und Verfahren die Wahrnehmung eines Nutzers, indem ein Digitalasset als eine einzige gepackte Datei präsentiert wird, während zudem die Vorteile, die mit dem Speichern und Synchronisieren einzelner Komponenten innerhalb der gepackten Datei einhergehen, genutzt werden. Des Weiteren stellen die Systeme und Verfahren eine Digitalassetverwaltung und eine verbesserte Synchronisierung zwischen einer Clientvorrichtung und einem Cloudspeichersystem bereit.
Demonstrationshalber halten die offenbarten Systeme und Verfahren eine Komponentendatenbank auf einer Clientvorrichtung vor, wobei die Komponentendatenbank Komponenten und ein Manifest für jedes Digitalasset speichert. Insbesondere zeigt jedes der Manifeste in der Komponentendatenbank an, welche Komponenten in der Komponentendatenbank ein Digitalasset bilden. Des Weiteren speichert die Komponentendatenbank die Komponenten als unabhängige Dateien, die über die Komponentendatenbank und/oder die Rechenvorrichtung hinweg gespeichert sind. Zusätzlich weist jedes Digitalasset eine Abbildung auf, die angibt, wo jede Komponente des Digitalassets innerhalb der Komponentendatenbank befindlich ist und/oder ob die Komponenten innerhalb einer gepackten Datei beinhaltet sind.
Zusätzlich erzeugen die Systeme und Verfahren eine gepackte Datei eines Digitalassets. Insbesondere kopieren die Systeme und Verfahren jede Komponente, die zu dem Digitalasset gehört, aus der Komponentendatenbank. Die Systeme und Verfahren packen sodann die Komponentenkopien in eine gepackte Datei. Beim Erzeugen der gepackten Datei aktualisieren die Systeme und Verfahren die Abbildung (beispielsweise den Pfad) für jede Komponente in dem Digitalasset und verweisen auf die gepackte Datei und nicht auf in der Komponentendatenbank gespeicherte Dateien. Beim Aktualisieren der Digitalassetabbildung für den Verweis auf den Ort der gepackten Datei können die Systeme und Verfahren die in der Komponentendatenbank gespeicherten entsprechenden Komponenten entfernen, um duplizierte Kopien der Komponenten zu beseitigen.
Bei einigen Ausführungsformen detektieren die offenbarten Systeme und Verfahren eine Modifikation an einer Komponente eines Digitalassets. Ein Cloudspeichersystem oder eine Anwendung auf einer Clientvorrichtung stellt beispielsweise eine Benachrichtigung im Zusammenhang mit Modifikationen an einer oder mehreren Komponenten des Digitalassets bereit. Beim Detektieren der Modifikation an einer Komponente erstellen oder speichern die Systeme und Verfahren eine aktualisierte Kopie der Komponente (das heißt eine separate Datei) in der Komponentendatenbank, die die Modifikationen an der Komponente beinhaltet.
Des Weiteren ersetzen die Systeme und Verfahren die Komponente durch die aktualisierte Kopie der Komponente in dem Manifest für das Digitalasset (sie erstellen beispielsweise ein neues Manifest, das die aktualisierte Kopie der mit dem Digitalasset verknüpften Komponente identifiziert) und erzeugen zudem eine modifizierte gepackte Datei, die die aktualisierte Kopie der Komponente beinhaltet. Zusätzlich aktualisieren die Systeme und Verfahren die Abbildung des Digitalassets zur Angabe dessen, dass die aktualisierte Kopie der Komponente in der modifizierten gepackten Datei gespeichert ist. Nach dem Aktualisieren der Abbildung und dem Erzeugen der modifizierten gepackten Datei können die Systeme und Verfahren gegebenenfalls die Kopie der Komponente aus der Komponentendatenbank entfernen. Bei einigen Ausführungsformen synchronisieren die Systeme und Verfahren die Komponente und die Kopie der Komponente mit dem Cloudspeichersystem vor dem Entfernen dieser Dateien aus der Komponentendatenbank.
Diese und weitere Merkmale und Vorteile einer oder mehrerer Ausführungsformen der vorliegenden Offenbarung werden in der nachfolgenden Beschreibung näher erläutert, erschließen sich teilweise aus der Beschreibung oder ergeben sich durch praktische Umsetzung exemplarischer Ausführungsformen.
Figurenliste
Die Offenbarung beschreibt eine oder mehrere Ausführungsformen mit zusätzlicher Spezifität und Dateigenauigkeit anhand der begleitenden Zeichnung, die sich wie folgt zusammensetzt.

1 zeigt eine exemplarische gepackte Datei eines Digitalassets, das aus mehreren Komponenten gebildet ist, entsprechend einer oder mehreren Ausführungsformen.
2 zeigt ein Blockdiagramm einer Umgebung, in der ein Digitalassetsynchronisierungssystem betrieben werden kann, entsprechend einer oder mehreren Ausführungsformen.
3 bis 12 zeigen verschiedene Sequenzdiagramme des Digitalassetsynchronisierungssystems beim Verwalten und Synchronisieren von Komponenten eines Digitalassets zwischen einer Komponentendatenbank und gepackten Dateien entsprechend einer oder mehreren Ausführungsformen.
13 zeigt ein Zustandsdiagramm des Digitalassetsynchronisierungssystems beim Vorhalten der Speicherung einer oder mehrerer Komponenten eines Digitalassets zwischen einer Komponentendatenbank und einer gepackten Datei entsprechend einer oder mehreren Ausführungsformen.
14 zeigt ein exemplarisches Flussdiagramm eines Verfahrens zum Erzeugen einer gepackten Datei aus Komponenten eines Digitalassets, die als unabhängige Dateien gespeichert sind, entsprechend einer oder mehreren Ausführungsformen.
15 zeigt ein exemplarisches Flussdiagramm eines Verfahrens zum Erzeugen einer modifizierten gepackten Datei entsprechend einer oder mehreren Ausführungsformen.
16 zeigt ein Blockdiagramm einer exemplarischen Rechenvorrichtung entsprechend einer oder mehreren Ausführungsformen.

Detailbeschreibung
Eine oder mehrere Ausführungsformen der vorliegenden Offenbarung beinhalten ein Digitalassetsynchronisierungssystem, das eine verbesserte Lokal- und Remote-Synchronisierung von Digitalassets ermöglicht. Insbesondere verwaltet das Digitalassetsynchronisierungssystem Digitalassets durch Separieren eines jeden Digitalassets in dessen intrinsische Komponenten und einzelnes Verwalten/Synchronisieren der Komponenten anstelle der gesamten Digitalassets. Demonstrationshalber identifiziert das Digitalassetsynchronisierungssystem bei einer oder mehreren Ausführungsformen Komponenten eines Digitalassets. Beim Identifizieren der Komponenten eines Digitalassets weist das Digitalassetsynchronisierungssystem Kennungen zu, die jede Komponente eindeutig identifizieren. Das Digitalassetsynchronisierungssystem speichert jede der Komponenten des Digitalassets als unabhängige Datei in einer Komponentendatenbank und nicht in einer monolithischen Datei. Wird eine Komponente modifiziert, so speichert das Digitalassetsynchronisierungssystem eine aktualisierte Version der Komponente und synchronisiert die aktualisierte Version der Komponente.
Des Weiteren ermöglicht das Digitalassetsynchronisierungssystem, dass ein Satz von Komponenten, der ein Digitalasset bildet, als eine einzige gepackte Datei erscheint, während die Vorteile des Verwaltens und Synchronisierens der Komponenten und eben nicht der gesamten Datei erhalten bleiben. Auf diese Weise bildet das Digitalassetsynchronisierungssystem eine Brücke zwischen den einzelnen verwalteten und synchronisierten Komponenten, die ein Digitalasset bilden, einerseits und herkömmlichen Dateiformaten und dem Aussehen von Dateien andererseits.
Demonstrationshalber hält das Digitalassetsynchronisierungssystem bei einer oder mehreren Ausführungsformen eine Komponentendatenbank auf einer Clientvorrichtung vor, wobei die Komponentendatenbank Komponenten sowie ein oder mehrere Manifeste für ein Digitalasset speichert. Jedes Manifest gibt einen Satz von Komponenten an, die ein Digitalasset bilden. Darüber hinaus ist jedes Manifest mit einer Abbildung verknüpft, die angibt, wo die Komponente in der Komponentendatenbank oder anderswo auf der Clientvorrichtung (beispielsweise in einer gepackten Datei) abgelegt ist. Auf diese Weise gibt die Komponentendatenbank an, welche Komponenten in der Komponentenbank das Digitalasset bilden und wo die Komponenten abgelegt sind. Die Komponentendatenbank speichert die Komponenten zudem als unabhängige Dateien, die über die Komponentendatenbank und/oder Rechenvorrichtung hinweg verteilt sind.
Auf Grundlage dessen, dass die Komponenten eines Digitalassets in der Komponentendatenbank gespeichert sind, erzeugt das Digitalassetsynchronisierungssystem bei einer oder mehreren Ausführungsformen eine gepackte Datei des Digitalassets. Insbesondere kopiert das Digitalassetsynchronisierungssystem jede Komponente, die zu dem Digitalasset gehört, aus der Komponentendatenbank. Das Digitalassetsynchronisierungssystem packt die Komponentenkopien sodann in eine gepackte Datei (beispielsweise in der Packung ADOBE® CREATIVE CLOUD® („CCP“), einer zip-Datei, einer PDF-Datei, einem anderen Format zur Dateikompression oder einem anderen Format für gepackte Dateien). Beim Erzeugen der gepackten Datei aktualisiert das Digitalassetsynchronisierungssystem die Abbildung für jede Komponente des Digitalassets und verweist auf die gepackte Datei und eben nicht auf die Komponentendatenbank. Nach dem Aktualisieren der Abbildung für jede Komponente entfernt das Digitalassetsynchronisierungssystem die Komponenten, die in der Komponentendatenbank gespeichert sind, um duplizierte Kopien der Komponenten auf der Clientvorrichtung zu beseitigen.
Das Digitalassetsynchronisierungssystem synchronisiert bei einigen Ausführungsformen zudem Komponenten des Digitalassets vor dem Entfernen derselben aus der Komponentendatenbank. Vor dem Entfernen der Komponenten des Digitalassets aus der Komponentendatenbank synchronisiert das Digitalassetsynchronisierungssystem die Komponenten beispielsweise mit einem Cloudspeichersystem. Auf diese Weise kann, wenn ein Packungsfehler auftritt, so beispielsweise wenn eine Komponente fehlt oder beschädigt wird, das Digitalassetsynchronisierungssystem die nicht vorhandene oder beschädigte Komponente aus dem Cloudspeichersystem abrufen und das Digitalasset erneut in eine gepackte Dateien packen.
Zusätzlich kann das Digitalassetsynchronisierungssystem eine Modifikation an einer Komponente eines Digitalassets detektieren. Ein Cloudspeichersystem gibt beispielsweise gegenüber dem Digitalassetsynchronisierungssystem auf der Clientvorrichtung an, dass eine Komponente aktualisiert worden ist. Bei einem weiteren Beispiel stellt eine Anwendung oder ein Betriebssystemprozess auf der Clientvorrichtung eine Benachrichtigung für das Digitalassetsynchronisierungssystem im Zusammenhang mit einer oder mehreren aktualisierten Komponenten eines Digitalassets bereit. Beim Detektieren der Modifikation an einer Komponente erstellt oder speichert das Digitalassetsynchronisierungssystem eine aktualisierte Kopie der Komponente (das heißt eine separate Datei) innerhalb der Komponentendatenbank, die die modifizierte Komponente beinhaltet.
Des Weiteren aktualisiert das Digitalassetsynchronisierungssystem das Manifest eines Digitalassets durch Ersetzen der alten Komponente (beispielsweise einer Kennung, die mit der Komponente verknüpft ist) durch eine aktualisierte Komponente (beispielsweise eine Kennung, die mit der aktualisierten Komponentenkopie verknüpft ist). Zusätzlich erzeugt das Digitalassetsynchronisierungssystem eine modifizierte gepackte Datei, die die aktualisierte Komponentenkopie beinhaltet, indem entweder die aktualisierte Komponentenkopie an die ursprüngliche gepackte Datei angefügt wird oder eine neue gepackte Datei mit der aktualisierten Komponentenkopie und eben nicht der Komponente erzeugt wird. Zudem aktualisiert das Digitalassetsynchronisierungssystem die Abbildung und verweist auf die aktualisierte Komponentenkopie in der neuen gepackten Datei und eben nicht in der Komponentendatenbank. Nach dem Aktualisieren der Abbildung und dem Erzeugen der modifizierten gepackten Datei entfernt das Digitalassetsynchronisierungssystem die Komponentenkopie (und die Komponente) aus der Komponentendatenbank. Wie vorstehend beschrieben worden ist, synchronisiert das Digitalassetsynchronisierungssystem bei einigen Ausführungsformen die Komponente und die Kopie der Komponente mit dem Cloudspeichersystem, bevor diese Komponenten aus der Komponentendatenbank entfernt werden.
Bei einigen Ausführungsformen hält das Digitalassetsynchronisierungssystem vorherige Versionen eines oder mehrerer Digitalassets vor. Die Komponentendatenbank speichert beispielsweise Manifeste, die vorherigen Versionen eines Digitalassets entsprechen. Die Komponentendatenbank und/oder das Cloudspeichersystem können des Weiteren Manifeste eines Digitalassets speichern, die Komponenten angeben, die bei vorherigen Digitalassetversionen genutzt werden. Verfolgt das Digitalassetsynchronisierungssystem Versionen eines Digitalassets, so kann das Digitalassetsynchronisierungssystem sicherstellen, dass die gepackte Datei die aktuellste Version eines Digitalassets darstellt. Auf diese Weise stellt, wenn ein Nutzer die gepackte Datei an einen Ort außerhalb des Digitalassetsynchronisierungssystems verschiebt oder kopiert, wenn er also beispielsweise die gepackte Datei an einen anderen Nutzer mailt, das Digitalassetsynchronisierungssystem sicher, dass der Nutzer mit der aktuellsten Version des Digitalassets arbeitet.
Beim Synchronisieren von Komponenten mit dem Cloudspeichersystem muss das Digitalassetsynchronisierungssystem lediglich eine neue oder aktualisierte Komponente eines Digitalassets und eben nicht jede Komponente, die das Digitalasset bildet, mit dem Cloudspeichersystem synchronisieren. Mit anderen Worten, das Digitalassetsynchronisierungssystem muss lediglich einen kleinen Teil eines Digitalassets beim Aktualisieren oder Modifizieren des Digitalassets synchronisieren. Da gepackte Dateien aus Komponenten bestehen, nutzt das Digitalassetsynchronisierungssystem zudem dieselben Bandbreite sparenden Techniken beim Synchronisieren eines aktualisierten Digitalassets, das als gepackte Datei dargestellt ist.
Wie vorstehend beschrieben worden ist, verschiebt ein Nutzer in einigen Fällen eine gepackte Datei nach außerhalb des Digitalassetsynchronisierungssystems. Auf ähnliche Weise verschiebt der Nutzer bei verschiedenen Ausführungsformen eine gepackte Datei in das Digitalassetsynchronisierungssystem. Allgemein bedeutet dies, dass das Digitalassetsynchronisierungssystem ein überwachtes Dateiverzeichnis (beispielsweise einen Ordner) vorhält, der ein oder mehrere Teilverzeichnisse (beispielsweise Ordner innerhalb von Ordnern) auf einer Clientvorrichtung beinhaltet. Das Digitalassetsynchronisierungssystem synchronisiert jede Datei innerhalb des überwachten Verzeichnisses mit dem Cloudspeichersystem. Darüber hinaus überwacht das Digitalassetsynchronisierungssystem jede Datei innerhalb des überwachten Dateiverzeichnisses, um zu detektieren, wann sich eine Komponente (beispielsweise entweder in einer gepackten Datei oder in einer Komponentendatenbank) ändert. Entsprechend kann, wie nachstehend noch beschrieben wird, das Digitalassetsynchronisierungssystem eine gepackte Datei herausnehmen (beispielsweise die Überwachung beenden), wenn die Datei nach außerhalb des überwachten Dateiverzeichnisses verschoben wird, und eine gepackte Datei anhängen oder erneut anhängen, wenn diese in das überwachte Dateiverzeichnis verschoben wird.
Bei zusätzlichen Ausführungsformen bietet das Digitalassetsynchronisierungssystem eine intelligente Konfliktbehebung beim Auftreten von Konflikten im Zusammenhang mit einem Digitalasset. Wie nachstehend noch beschrieben wird, kann, wenn das Digitalassetsynchronisierungssystem einen Konflikt zwischen verschiedenen Versionen eines Digitalassets auf Grundlage eines Vergleiches der jeder Version entsprechenden Manifeste detektiert, das Digitalassetsynchronisierungssystem in einem vorherigen Manifest fehlende Komponenten aus einem aktuelleren Manifest für das Digitalasset identifizieren und übernehmen. Wenn das Digitalassetsynchronisierungssystem zudem einen Konflikt zwischen verschiedenen Versionen derselben Komponente eines Digitalassets detektiert (beispielsweise zwischen einem Komponentenzweig und einem Cloudzweig), kann das Digitalassetsynchronisierungssystem beide Versionen der Komponente in das Digitalasset aufnehmen. Auf diese Weise ermöglicht das Digitalassetsynchronisierungssystem, dass ein Nutzer den Konflikt innerhalb des Digitalassets schnell erkennt und berichtigt.
Wie vorstehend kurz beschrieben worden ist, bietet das Digitalassetsynchronisierungssystem eine Anzahl von Vorteilen gegenüber herkömmlichen Dateiverwaltungssystemen. Das Digitalassetsynchronisierungssystem bietet beispielsweise eine größere Flexibilität für eine Clientvorrichtung, indem es eine Brücke zwischen Digitalassets, die durch Komponenten in einer Komponentendatenbank dargestellt werden, und gepackten Dateien, die einem Nutzer als monolithische Datei erscheinen, bildet, bietet jedoch gleichzeitig einen schnelleren Zugriff und eine schnellere Präsentation durch eine Clientvorrichtung.
Demonstrationshalber kann, da gepackten Dateien aus Komponenten bestehen, das Digitalassetsynchronisierungssystem diejenige Effizienz beweisen, die durch Synchronisieren lediglich modifizierter Komponenten eines Digitalassets und eben nicht durch Synchronisieren des gesamten Digitalassets erreicht werden. Wie hier detailliert dargestellt ist, bietet das Digitalassetsynchronisierungssystem eine verbesserte Effizienz für eine Clientvorrichtung, indem die Rechenressourcen, die von der Clientvorrichtung zum Synchronisieren und Speichern eines Digitalassets benötigt werden, verringert werden. Durch den Einsatz von Digitalassets, die als Komponenten entweder in einer Komponentendatenbank oder einer gepackten Datei gespeichert sind, stellt das Digitalassetsynchronisierungssystem einen schnelleren Zugriff (beispielsweise eine schnellere Suche) und eine schnellere Präsentation des Digitalassets bereit, was dazu führt, dass das Digitalassetsynchronisierungssystem die Funktionalität der Clientvorrichtung selbst verbessert (beispielsweise bewerkstelligt das Digitalassetsynchronisierungssystem das Zugreifen, Anzeigen und Bearbeiten von Digitalassets schneller als herkömmliche Systeme und Verfahren).
Bei einem zusätzlichen Vorteil bietet das Digitalassetsynchronisierungssystem eine größere Flexibilität und eine verbesserte Rechenfunktionalität, indem es einen gleichzeitigen Zugriff und eine gleichzeitige Bearbeitung desselben Digitalassets durch mehrere Nutzer, Anwendungen und/oder Vorrichtungen ermöglicht. Detektiert das Digitalassetsynchronisierungssystem eine Änderung einer Komponente eines Digitalassets, so gibt das Digitalassetsynchronisierungssystem die Änderung automatisch an andere Nutzer, Anwendungen und/oder Vorrichtungen weiter, die zur gleichen Zeit auf das Digitalasset zugreifen. Herkömmliche Systeme und Verfahren ermöglichen keinen gleichzeitigen Zugriff und keine gleichzeitige Bearbeitung ein und desselben Digitalassets durch mehrere Nutzer, Anwendungen und/oder Vorrichtungen. Darüber hinaus behebt das Digitalassetsynchronisierungssystem, wenn ein Konflikt mit einer Komponente detektiert wird, den Konflikt, wie bereits erwähnt worden ist, intelligent.
Darüber hinaus müssen die einzelnen Anwendungen als Ergebnis dessen, dass das Digitalassetsynchronisierungssystem einen gleichzeitigen Zugriff auf Komponenten zwischen Anwendungen auf einer Clientvorrichtung ermöglicht, keine Inter-Prozess-Kommunikationen (IPC) bereitstellen, wenn sich eine Komponente innerhalb der Anwendung ändert. Vielmehr nimmt das Digitalassetsynchronisierungssystem das Detektieren, Verwalten und Koordinieren der modifizierten Komponente über mehrere Anwendungen hinweg vor. Dieses Merkmal ist insbesondere bei Sandbox-Systemen und in ähnlichen Umgebungen von Belang, wo verhindert wird, dass Anwendungen IPC für die Kommunikation mit anderen Anwendungen auf einer Clientvorrichtung nutzen. Der weitere Nutzen sowie weitere Vorteile, Merkmale und Eigenschaften des Digitalassetsynchronisierungssystems werden nachstehend anhand der Figuren beschrieben, die eine oder mehrere Ausführungsformen des Digitalassetsynchronisierungssystems beschreiben.
In der Zeichnung zeigt 1 eine exemplarische gepackte Datei 100 eines Digitalassets 102. Wie gezeigt ist, beinhaltet die gepackte Datei 100 mehrere Komponenten 104, die das Digitalasset 102 bilden. Bei einigen Ausführungsformen bilden Tausende von Komponenten 104 ein Digitalasset 102. Das Digitalassetsynchronisierungssystem kann zudem ein Manifest erzeugen, das jede Komponente, die das Digitalasset 102 bildet, auflistet. Unter Einsatz der gepackten Datei bewirkt das Digitalassetsynchronisierungssystem, dass das Digitalasset 102 als eine einzige monolithische Datei und nicht als Sammlung von Komponenten 104, die das Digitalasset 102 bilden, erscheint. Mit anderen Worten, die Clientvorrichtung zeigt das Digitalasset 102 als eine einzige Datei an, die der Nutzer auswählen, öffnen, verschieben, kopieren und dergleichen mehr kann, ohne dass der Nutzer wahrnimmt, dass das Digitalasset 102 eine Sammlung von mehreren Komponentendateien ist.
Einfachheitshalber bezeichnet der Begriff „Digitalasset“ im Sinne des Vorliegenden allgemein Digitaldaten, an denen entsprechende Nutzungsrechte vorhanden sind. Ein Nutzer ist beispielsweise berechtigt, ein Digitalasset zu erstellen, zu betrachten, zu modifizieren und/oder zu löschen. Beispiele für ein Digitalasset beinhalten unter anderem Dokumente, so beispielsweise Textdokumente, Tabellen und Präsentationen; elektronische Nachrichten; Bilder, so beispielsweise Illustrationen, Animationen und Fotos; Videos, Audiocontent; dreidimensionale Daten; und andere Digitaldaten, die ein Nutzer zwischen Rechenvorrichtungen übertragen kann.
Der Begriff „Komponente“ bezeichnet einen Teil eines Digitalassets. Ein bestimmter Satz oder eine bestimmte Sammlung von Komponenten bildet ein Digitalasset (beispielsweise eine Digitalassetversion). Im Allgemeinen ist jede Komponente eines Digitalassets modifizierbar, ohne dass dies andere Komponenten des Digitalassets beeinflussen würde. Als solches kann auf eine Datei separat von anderen Datendateien zugegriffen werden, und sie kann modifiziert, übertragen und/oder entfernt werden. Da Komponenten diskrete Teile eines Digitalassets sind, kann jede Komponente auf einer Rechenvorrichtung als eine einzelne Datei an einem Dateiort oder in einem Verzeichnis gespeichert sein, wobei dies nicht davon abhängt, wo andere Komponenten des Digitalassets gespeichert sind. Im Gegensatz zu einer monolithischen Datei, die sämtliche zu der Datei gehörenden Daten an einem einzigen Ort speichert, können Komponenten eines Digitalassets als Dateien gespeichert werden, die über ein Speichermedium verteilt sind, so beispielsweise auf einer oder mehreren Clientvorrichtungen und/oder Remote-Servervorrichtungen. In einigen Fällen ist beispielsweise eine beschränkte Anzahl von Komponenten wechselseitig verknüpft, wobei Änderungen an einer Komponente eine beschränkte Anzahl von anderen Komponenten betreffen. Zusätzlich beruht der Stil (beispielsweise das Framework) einer Komponente auf Grenzen innerhalb eines Digitalassets und oftmals auf dem Typ des Digitalassets. Ein Bild beinhaltet beispielsweise Schichten und Teilschichten als Komponenten; ein Video- oder Videoprojekt beinhaltet kürzere Videosegmente, Titel und statische Grafiken als Komponenten; ein Dokument beinhaltet Seiten, Leinwände, Zeichenhintergründe, Text- und Bildkästchen, Reihen, Spalten und/oder Grafiken als Komponenten; ein dreidimensionales Modell beinhaltet Netze, Karten, Szenen und Gitternetze. In einigen Fällen kann ein Nutzer die Grenzen/Parameter für Komponenten eines Digitalassets definieren.
Darüber hinaus ist jede Komponente zu einer bestimmten Zeit eine unabhängige Datei. Im Sinne des Vorliegenden bezeichnet der Begriff „unabhängige Datei“ (oder einfach „Datei“) allgemein Digitaldaten, die einzeln in einem Speichermedium aufgezeichnet sind. Als solches kann auf eine Datei getrennt von anderen Datendateien zugegriffen werden, und sie kann modifiziert, übertragen und/oder entfernt werden. Da Komponenten diskrete Abschnitte eines Digitalassets sind, kann jede Komponente auf einer Rechenvorrichtung als eine einzelne Datei an einem Dateiort oder in einem Verzeichnis gespeichert werden, wobei dies nicht davon abhängt, wo andere Komponenten des Digitalassets gespeichert sind. Als solches können Komponenten eines Digitalassets als Dateien gespeichert sein, die über ein Speichermedium hinweg, so beispielsweise eine oder mehrere Clientvorrichtungen und/oder Remote-Servervorrichtungen, verteilt sind.
Bei einigen Ausführungsformen sind, wie hier beschrieben wird, mehrere Komponenten zusammen in einer gepackten Datei gespeichert. Im Sinne des Vorliegenden bezeichnet der Begriff „gepackte Datei“ allgemein eine Sammlung von Komponenten, die ein Digitalasset bilden und die das Digitalasset als eine einzige monolithische Datei darstellen. Im Allgemeinen ist die Sammlung von Komponenten des Digitalassets innerhalb der einzigen Datei, die das Digitalasset darstellt, gruppiert.
Darüber hinaus kann eine gepackte Datei komprimierte oder archivierte Komponenten eines Digitalassets beinhalten. Eine gepackte Datei ist beispielsweise eine Packung von ADOBE® CREATIVE CLOUD® („ccp“), eine zip-Datei oder eine PDF-Datei (PDF, portables Dokumentformat). Darüber hinaus ist bei verschiedenen Ausführungsformen eine gepackte Datei mit einem bestimmten Dateityp verknüpft, der durch eine bestimmte Dateierweiterung angegeben ist. Eine gepackte Datei kann zudem Komponenten eines Digitalassets beinhalten, die die aktuellste Version des Digitalassets darstellen. In einigen Fällen beinhaltet die gepackte Datei zudem alle Komponenten, die zu einer oder mehreren vorherigen Versionen des Digitalassets gehören. Der Begriff „gepackte Datei“ kann zu den Begriffen „gepackte Komponentendatei“, „Snapshot“, „Snapshotdatei“, „Komponentensnapshot“, „Digitalassetsnapshot“, „Headversion“, „Dateidarstellung“, „Einzelansichtsdatei“, „Verbunddatei“ und „Verbund“ synonym sein.
Vorstehend ist anhand 1 ausgeführt worden, dass die gepackte Datei 100 das Digitalasset 102 als monolithische Datei und nicht als Sammlung von Komponenten 104, die als unabhängige Dateien gespeichert sind, anzeigt. Auf diese Weise zeigt die Clientvorrichtung das Digitalasset 102 als eine einzige Datei innerhalb eines Dateiverzeichnisses an. Des Weiteren ermöglicht das Darstellen des Digitalassets 102 als gepackte Datei 100, dass ein Nutzer das Digitalasset 102 von einem Verzeichnis einer Clientvorrichtung zu einem anderen Verzeichnis oder zu einer anderen Komponentenvorrichtung (einer Servervorrichtung oder einer anderen Clientvorrichtung) verschieben und/oder kopieren kann. Als solches bietet die gepackte Datei 100 einem Nutzer die vertraute Erfahrung, mit herkömmlichen Dateien (das heißt mit einzelnen monolithischen Dateien ohne Komponenten) zu arbeiten. Insbesondere erzeugen eine oder mehrere Ausführungsformen eine gepackte Datei 100 aus Komponentendateien, die ein Rechensystem (beispielsweise WINDOWS EXPLORER, FINDER, NAUTILUS, DOLPHIN, XFE oder THUNAR) bereitstellt, während die Vorteile des Verwaltens und Synchronisierens der einzelnen Komponenten erhalten bleiben.
Obwohl das Digitalasset 102 als eine einzige monolithische Datei erscheint, bietet die gepackte Datei 100 des Weiteren die Vorteile, die durch die Verwendung von Komponenten, die ein Digitalasset bilden, bereitgestellt werden, was bei herkömmlichen Dateien nicht der Fall ist. Bei einem Beispiel ermöglichen Komponenten, dass mehrere Nutzer, Clientvorrichtungen und/oder Anwendungen gleichzeitig auf ein Digitalasset zugreifen. Bei einem weiteren Beispiel ermöglichen Komponenten, dass das Digitalassetsynchronisierungssystem kleine Teile eines Digitalassets zwischen einer Clientvorrichtung und einem Cloudspeichersystem oder zwischen mehreren Clientvorrichtungen effizient synchronisiert. Darüber hinaus ermöglichen die Komponenten, dass das Digitalassetsynchronisierungssystem mehrere Versionen eines Digitalassets vorhält, ohne dass vollständige Kopien einer jeden Version gespeichert werden. Diese und weitere Vorteile des Einsatzes von Komponenten für ein Digitalasset werden nachstehend anhand der nachfolgenden Figuren beschrieben.
2 zeigt ein Blockdiagramm einer Umgebung 200, in der ein Digitalassetverwaltungssystem 208 mit einem Digitalassetsynchronisierungssystem 210 entsprechend einer oder mehreren Ausführungsformen arbeiten kann. Wie in 2 gezeigt ist, beinhaltet die Umgebung 200 zwei Clientvorrichtungen (beispielsweise eine erste Clientvorrichtung 202 und eine zweite Clientvorrichtung 204), die mit einer Servervorrichtung 230 über ein Netzwerk 240 kommunizieren. Es sollte einsichtig sein, dass die Umgebung 200 in verschiedenen Ausgestaltungen vorliegen und auch mehr oder weniger Komponenten beinhalten kann. Die Umgebung 200 kann beispielsweise eine Anzahl von Clientvorrichtungen beinhalten. Eine oder mehrere Rechenvorrichtungen (beispielsweise eine Clientvorrichtung und/oder eine Servervorrichtung) können das Digitalassetverwaltungssystem implementieren.
Jede der in 2 gezeigten Clientvorrichtungen beinhaltet das Digitalassetverwaltungssystem 208 und eine oder mehrere Anwendungen 226. Vereinfachungshalber werden die Elemente des Digitalassetverwaltungssystems 208 und der einen oder mehreren Anwendungen 226 anhand der ersten Clientvorrichtung 202 beschrieben. Es sollte jedoch einsichtig sein, dass die Elemente des Digitalassetverwaltungssystems 208 und der einen oder mehreren Anwendungen 226 ähnliche Funktionen auf der zweiten Clientvorrichtung 204 wie auch auf anderen, nicht gezeigten Clientvorrichtungen wahrnehmen können.
Im Allgemeinen können die Clientvorrichtungen jeweils verschiedene Typen von Clientvorrichtungen darstellen. Bei einigen Ausführungsformen sind die erste Clientvorrichtung 202 und/oder die zweite Clientvorrichtung 204 beispielsweise eine Mobilvorrichtung, so beispielsweise ein Mobiltelefon, ein Smartphone, ein PDA, ein Tablet, ein Laptop, eine tragbare Vorrichtung und dergleichen mehr. Bei anderen Ausführungsformen sind die erste Clientvorrichtung 202 und/oder die zweite Clientvorrichtung 204 eine nichtmobile Vorrichtung, so beispielsweise ein Desktop oder ein Server, oder eine andere Art von Clientvorrichtung. Zusätzliche Details im Zusammenhang mit den Clientvorrichtungen werden nachstehend anhand 16 beschrieben.
Das Digitalassetverwaltungssystem 208 und das Digitalassetsynchronisierungssystem 210 können computerausführbare Anweisungen beinhalten, die bei Ausführung durch eine oder mehrere Rechenvorrichtungen veranlassen, dass die entsprechende eine oder die entsprechenden mehreren Rechenvorrichtungen eine Anzahl von Aktionen ausführt/ausführen, die nachstehend noch detaillierter beschrieben werden. Des Weiteren setzt das Digitalassetverwaltungssystem 208 bei einer oder mehreren Ausführungsformen eine Digitalverbundtechnologie (oder Digitalkomponententechnologie) (auch als „DCX“ bezeichnet) ein, die das Framework für die Erstellung von Komponentensätzen (das heißt von gepackten Dateien), wie hier beschrieben wird, vereinfacht. Ein Großteil der nachfolgenden Beschreibung im Zusammenhang mit dem Digitalassetverwaltungssystem 208 betrifft entsprechend die Bereitstellung von DCX.
Wie in 2 dargestellt ist, beinhaltet das Digitalassetverwaltungssystem 208 auf der ersten Clientvorrichtung 202 ein Synchronisierungssystem 210 mit einem Komponentenverwalter 212, einem Überwachungsagent 220, einem Packungsverwalter 222 und gepackten Dateien 224. Der Komponentenverwalter 212 beinhaltet des Weiteren eine Komponentendatenbank 214 (beispielsweise einen Synchronisierungsspeicher), die Komponenten 216 von Digitalassets und entsprechende Digitalassetmanifeste 218 speichert. Es sollte einsichtig sein, dass das Digitalassetverwaltungssystem 208 zusätzliche oder weniger Elemente, die die nachstehend beschriebenen Funktionen wahrnehmen, beinhalten kann.
Kontexthalber halten das Digitalassetverwaltungssystem 208 und das Digitalassetsynchronisierungssystem 210 (wenigstens) zwei Kategorien eines Digitalassets vor. Die erste Kategorie beinhaltet Digitalassets, deren Komponenten in der Komponentendatenbank 214 gespeichert sind. Die zweite Kategorie beinhaltet Digitalassets, deren Komponenten oftmals in den gepackten Dateien 224 gespeichert sind. Darüber hinaus kann das Digitalassetsynchronisierungssystem zudem Digitalassets, die herkömmliche monolithische Dateien und keine Komponenten beinhalten, speichern.
Im Allgemeinen wird die erste Kategorie von Digitalassets von dem Komponentenverwalter 212 verwaltet, während die zweite Kategorie von Digitalassets von dem Überwachungsagent 220 (beispielsweise einem Core-Synchronisierungsagent) und dem Packungsverwalter 222 verwaltet wird. Während des Verwaltens der gepackten Dateien 224 treten jedoch oftmals Kommunikationen und Überlappungen zwischen dem Komponentenverwalter 212, dem Überwachungsagent 220 und dem Packungsverwalter 222 auf.
Darüber hinaus zeigt die Clientvorrichtung Icons (oder andere grafische Dateidarstellungen) der gepackten Dateien 224 innerhalb eines Dateiverzeichnisses (beispielsweise eines überwachten Dateiverzeichnisses) an. Im Gegensatz hierzu sind die nichtgepackten Dateien im Allgemeinen nur über eine Anwendungsschnittstelle sichtbar. Die Anwendung präsentiert beispielsweise eine Liste von Digitalassets, die in der Komponentendatenbank gespeichert sind, in einem Dateiverzeichnis jedoch nicht direkt zu finden sind. Zusätzliche Details im Zusammenhang mit jeder Kategorie von Digitalassets werden nunmehr angegeben.
Der Komponentenverwalter 212 erleichtert allgemein das Speichern eines Digitalassets, das in Form von Komponenten innerhalb der Komponentendatenbank 214 gespeichert ist, sowie den Zugriff hierauf und die Synchronisierung hiervon. Der Komponentenverwalter 212 speichert beispielsweise Komponenten 216 eines Digitalassets als unabhängige Dateien, die über die Komponentendatenbank 214 hinweg verteilt sind. Darüber hinaus erstellt der Komponentenverwalter 212 ein oder mehrere Digitalassetmanifeste 218, die eine oder mehrere Versionen des Digitalassets jeweils mit den Komponenten 216 verknüpfen. Als solches wird, wenn ein Digitalasset in der Komponentendatenbank 214 gespeichert ist, dieses üblicherweise nicht als eine einzelne Datei innerhalb eines Dateiverzeichnisses, sondern als unabhängige Komponentendateien dargestellt. Betrachtet ein Nutzer das Digitalasset jedoch innerhalb einer Anwendung, so ermöglicht der Komponentenverwalter 212, dass die Anwendung das Digitalasset als eine einzige monolithische Datei, wie nachstehend noch beschrieben wird, anzeigt.
Wie vorstehend erwähnt worden ist, erzeugt, speichert und modifiziert der Komponentenverwalter 212 die Digitalassetmanifeste 218 (oder einfach die „Manifeste“ 218) eines oder mehrerer Digitalassets. Insbesondere beinhaltet jedes der Manifeste 218 eine Auflistung der Komponenten 216, die ein Digitalasset bilden. Bei einigen Ausführungsformen definiert ein Manifest eine Reihenfolge, eine Priorität oder eine Anordnung von Komponenten des Digitalassets, wie nachstehend noch beschrieben wird. Ein Manifest für ein Digitalbild (das heißt ein Digitalasset) gibt beispielsweise Schichten (das heißt Komponenten) an, die das Digitalbild bilden. Des Weiteren identifiziert das Manifest die Reihenfolge und/oder Priorität einer jeden Schicht innerhalb des Digitalbildes.
Jedes der Manifeste 218 für ein Digitalasset kann eine Kennung (das heißt eine „ID“) und in einigen Fällen eine Abbildung (beispielsweise einen Pfad) beinhalten. Im Allgemeinen markiert eine Kennung jede Komponente, die ein Digitalasset bildet, eindeutig. Der Komponentenverwalter 212 verwendet Komponentenkennungen zur Auflistung der Komponenten, die ein Digitalasset bilden, in einem Manifest. Die Abbildung gibt einen Datenbankort und/oder einen Dateipfad einer gepackten Datei an, wo eine Komponente gespeichert ist. Bei einigen Ausführungsformen speichert der Komponentenverwalter 212 die Abbildung für jedes Digitalasset in der Komponentendatenbank 214. Wie vorstehend erwähnt worden ist, sind Komponenten als unabhängige Dateien, die über ein Speichermedium, so beispielsweise die Komponentenbank 214, oder anderswo auf der ersten Clientvorrichtung 202 verteilt sind, gespeichert.
Wie erwähnt worden ist, hält die Komponentendatenbank 214 bei einigen Ausführungsformen eine Abbildung vor, die angibt, wann eine Komponente in einer gepackten Datei und nicht in der Komponentendatenbank 214 gespeichert ist. Derartige Ausführungsformen werden nachstehend erläutert. Bei anderen Ausführungsformen gibt die Abbildung an, dass eine Komponente in dem Cloudsynchronisierungssystem 232 gespeichert ist. Die Komponentendatenbank 214 hält ein vorheriges Manifest eines Digitalassets vor, das eine oder mehrere veraltete Komponenten beinhaltet. Anstatt die veralteten Komponenten weiter in der Komponentendatenbank 214 zu speichern, synchronisiert der Komponentenverwalter 212 die Komponenten mit dem Cloudsynchronisierungssystem 232 vor dem Entfernen der Komponenten aus der Komponentendatenbank 214 und/oder der ersten Clientvorrichtung 212. Des Weiteren aktualisiert der Komponentenverwalter 212 eine Abbildung zur Angabe dessen, dass die veralteten Komponenten auf dem Komponentenverwalter 232 gespeichert sind.
Wie vorstehend erwähnt worden ist, kann der Komponentenverwalter 212 Versionshistorien eines Digitalassets auf Grundlage der Speicherung von Manifesten vorheriger Versionen eines Digitalassets vorhalten. Demonstrations- und beispielshalber sei angenommen, dass ein Digitalasset drei Komponenten beinhaltet. Der Komponentenverwalter 212 erstellt ein Manifest, das die drei Komponenten und ihre entsprechende Abbildung identifiziert. Das Manifest stellt Version 1 des Digitalassets dar. Beim Empfangen einer Aktualisierung für die erste Komponente des Digitalassets erzeugt der Komponentenverwalter 212 ein aktualisiertes Manifest, das die Kennung/Abbildung mit der ursprünglichen ersten Komponente durch die Kennung/Abbildung der aktualisierten ersten Komponente ersetzt, die einer neuerstellten Datei entspricht, die die erste Komponente in ihrer aktualisierten Form beinhaltet und separat in der Komponentenbank 214 gespeichert ist. Das aktualisierte Manifest stellt Version 2 des Digitalassets dar.
Bei diesem Beispiel hält der Komponentenverwalter 212 mehrere Versionen des Digitalassets vor, indem er nur eine zusätzliche Komponente für das Digitalasset (beispielsweise die ursprünglichen drei Komponenten und die aktualisierte erste Komponente) speichert. Will ein Nutzer Version 1 des Digitalassets betrachten, so greift der Komponentenverwalter 212 auf die ursprünglichen drei Komponenten unter Verwendung des ursprünglichen Manifests und der entsprechenden Abbildung zu. Will der Nutzer Version 2 des Digitalassets betrachten, so verwendet der Komponentenverwalter 212 das aktualisierte Manifest und die entsprechende Abbildung für den Zugriff auf die aktualisierte erste Komponente zusammen mit der ursprünglichen zweiten Komponente und der ursprünglichen dritten Komponente.
Bei einigen Ausführungsformen entfernt der Komponentenverwalter 212 vorherige Komponenten aus der Komponentendatenbank 214 und/oder von der ersten Clientvorrichtung 202, um Speicherplatz auf der ersten Clientvorrichtung 202 freizumachen. Der Komponentenverwalter 212 löscht beispielsweise die erste ursprüngliche Komponente aus der Komponentendatenbank 214. Vor dem Entfernen der ursprünglichen ersten Komponente stellt der Komponentenverwalter 212 jedoch sicher, dass eine Reservekopie (Back-up) der ursprünglichen ersten Komponente in dem Cloudsynchronisierungssystem 232 gespeichert wird. Der Komponentenverwalter 212 stellt beispielsweise sicher, dass die ursprüngliche erste Komponente mit dem Cloudspeichersystem synchronisiert ist, bevor die ursprüngliche erste Komponente aus der Komponentendatenbank 214 entfernt wird.
Während der Komponentenverwalter 212 vorherige Komponenten von einer Clientvorrichtung, wie bei den vorstehenden Ausführungsformen beschrieben worden ist, entfernt, kann der Komponentenverwalter 212 auch auf der ersten Clientvorrichtung 202 eine Anzahl von Manifesten 218, die vorherigen Versionen eines Digitalassets entsprechen, vorhalten. Die Manifeste 218 für ein Digitalasset sind im Allgemeinen kleinere Textdateien (oder Datenbankeinträge), die wenig Speicherplatz benötigen. Zusätzlich und/oder alternativ stellt der Komponentenverwalter 212 Kopien eines jeden Manifests für vorherige Versionen eines Digitalassets für das Cloudsynchronisierungssystem 232 zur Speicherung bereit. Bei einigen Ausführungsformen hält die Komponentendatenbank 214 eine begrenzte Anzahl von vorherigen Versionsmanifesten für ein Digitalasset vor, während das Cloudsynchronisierungssystem 232 eine größere Anzahl von vorherigen Versionsmanifesten für das Digitalasset speichert.
Bei einer oder mehreren Ausführungsformen verwendet der Komponentenverwalter 212 ein Manifest, das jede vorherige Komponente, die in einem Digitalasset verwendet wird, beinhaltet. Demonstrationshalber beinhaltet wie beim vorbeschriebenen Beispiel das aktualisierte Manifest ein zusätzliches Feld, das die ursprüngliche erste Komponente als vorherige Version der aktualisierten ersten Komponente auflistet. Auf diese Weise kann ein Nutzer anfordern, dass der Komponentenverwalter 212 eine spezifische Komponente in eine vorherige Version rückverwandelt, während die anderen Komponenten in dem Digitalasset unbeeinflusst bleiben.
Der Komponentenverwalter 212 gemäß vorstehender Beschreibung erleichtert die Synchronisierung mit dem Cloudsynchronisierungssystem 232. Insbesondere stellt der Komponentenverwalter 212 bei der Erstellung eines Digitalassets oder einzelner Komponenten sicher, dass jede Komponente in dem Cloudsynchronisierungssystem 232 gespeichert ist. Zusätzlich kann der Komponentenverwalter 212 Transaktionsgarantien bereitstellen, so beispielsweise das Empfangen eines Nachweises, dass jede Komponente erfolgreich von dem Cloudsynchronisierungssystem 232 empfangen worden ist. Des Weiteren lädt, nachdem der Komponentenverwalter 212 auf der ersten Clientvorrichtung 202 Komponenten eines Digitalassets in das Cloudspeichersystem 232 hochlädt, der Komponentenverwalter 212 auf der zweiten Clientvorrichtung 204 die Komponenten des Digitalassets von dem Cloudspeichersystem 232 herunter.
Nach dem anfänglichen Synchronisieren eines Digitalassets muss der Komponentenverwalter 212 lediglich die einzelnen Komponenten, wenn diese modifiziert sind, synchronisieren. Beim Aktualisieren der ersten Komponente stellt wie beim vorbeschriebenen Beispiel der Komponentenverwalter 212 (beispielsweise durch Pushing) nur die aktualisierte erste Komponente für das Cloudsynchronisierungssystem 232 (und in einigen Fällen das aktualisierte Manifest, das Version 2 des Digitalassets darstellt) bereit. Auf diese Weise muss der Komponentenverwalter 212 nicht das gesamte Digitalasset in das Cloudsynchronisierungssystem 232 redundant hochladen.
Auf gleiche Weise kommuniziert der Komponentenverwalter 212, wenn das Cloudsynchronisierungssystem 232 gegenüber dem Komponentenverwalter 212 auf der ersten Clientvorrichtung 202 angibt, dass eine Komponente aktualisiert (beispielsweise modifiziert, hinzugefügt oder gelöscht) worden ist, mit dem Cloudsynchronisierungssystem 232, um die aktualisierte Komponente herunterzuladen. Der Komponentenverwalter 212 detektiert beim vorbeschriebenen Beispiel beispielsweise, dass eine vierte Komponente zu dem Digitalasset auf dem Cloudsynchronisierungssystem 232 hinzugefügt worden ist. Als solches fordert der Komponentenverwalter 212 (beispielsweise mittels Pulling) die Komponente von dem Cloudsynchronisierungssystem 232 an und aktualisiert das Manifest des Digitalassets, um die Aktualisierung auf der ersten Clientvorrichtung 202 wiederzugeben. Es sollte einsichtig sein, dass der Komponentenverwalter 212 mehrere Komponenten für ein oder mehrere Digitalassets mit dem Cloudsynchronisierungssystem 232 parallel synchronisieren kann.
In einigen Fällen treten Konflikte zwischen Komponenten eines Digitalassets auf. Beim Durchführen von parallelen Synchronisierungen mit dem Cloudsynchronisierungssystem 232 kann der Komponentenverwalter 212 beispielsweise Konflikte zwischen Zweigen (beispielsweise Manifesten) des Digitalassets detektieren. Allgemein stellen Zweige eine Version eines Digitalassets dar, die auf einer bestimmten Vorrichtung befindlich ist und die die bestimmte Vorrichtung als richtige Version betrachtet. Ein Digitalasset kann beispielsweise einen Zweig der Cloud, einen Zweig der ersten Clientvorrichtung, einen Zweig der zweiten Clientvorrichtung und einen Zweig der nachgewiesenen Synchronisierung aufweisen. Bei einem zusätzlichen Beispiel kann dieselbe Clientvorrichtung einen Zweig der Basis, einen Zweig einer ersten Anwendung und einen Zweig einer zweiten Anwendung aufweisen. Da das Digitalassetverwaltungssystem 208 und das Digitalassetsynchronisierungssystem 210 einen Zugriff auf ein Digitalasset von verschiedenen Vorrichtungen aus wie auch einen gleichzeitigen Zugriff von derselben Clientvorrichtung aus ermöglichen, können Konflikte zwischen Komponenten eines Digitalassets entstehen.
Des Weiteren können im Übrigen die nachstehend beschriebenen Konfliktbehebungsprinzipien „pluggbar“ (einsetzbar) sein, was bedeutet, dass das Digitalassetsynchronisierungssystem 210 optional eine oder mehrere der nachstehend beschriebenen Ausführungsformen einsetzen kann. Alternativ kann das Digitalassetsynchronisierungssystem 210 andere Ausführungsformen einer Konfliktbehebung als die beschriebenen einsetzen. Bei einigen Ausführungsformen setzt das Digitalassetsynchronisierungssystem 210 einen anderen Typ von Konfliktbehebung auf Grundlage des Formattyps oder des Dateityps einer gepackten Datei ein. Das Digitalassetsynchronisierungssystem 210 setzt beispielsweise bei einer gepackten Bilddatei eine andere Konfliktbehebung als bei einer gepackten Dokumentdatei ein.
Tritt ein Konflikt zwischen Komponenten in verschiedenen Zweigen eines Digitalassets auf, so kann der Komponentenverwalter 212 auch ein oder mehrere Verfahren und/oder eine oder mehrere Techniken zur Behebung des Konflikts einsetzen. Im Allgemeinen ist ein Konflikt, wenn er zwischen verschiedenen Versionen desselben Digitalassets auftritt, zwischen verschiedenen Komponenten des Digitalassets vorhanden, da Digitalassets oftmals aus einer großen Anzahl von Komponenten bestehen. Als solches kann der Komponentenverwalter 212 die Konflikte dadurch schlichten, dass er die aktuellsten Versionen einer jeden Komponente zu einer einzigen Version des Digitalassets zusammenführt und sodann die aktualisierte Version mit dem Cloudsynchronisierungssystem 232 synchronisiert.
Demonstrationshalber sei bei einem neuen Beispiel ein Digitalbild (das heißt ein Digitalasset), das fünfzig Schichten (beispielsweise Komponenten) beinhaltet, gegeben. Anfänglich weisen die erste Clientvorrichtung 202 und das Cloudsynchronisierungssystem 232 jeweils eine nachgewiesene synchronisierte Version (das heißt eine passende Version) des Digitalbildes auf. Nach dem Aktualisieren der ersten Schicht des Digitalbildes versucht der Komponentenverwalter 212, die lokal aktualisierte Version mit dem Cloudsynchronisierungssystem 232 zu synchronisieren. Während der Durchführung der Synchronisierung detektiert der Komponentenverwalter 212 jedoch, dass das Cloudsynchronisierungssystem 232 eine cloudaktualisierte Version aufweist, in der die zehnte Schicht modifiziert ist (beispielsweise hat die zweite Clientvorrichtung 204 die nunmehr cloudaktualisierte Version aktualisiert und hochgeladen), wobei die erste Schicht durch die nachgewiesene synchronisierte Version unverändert bleibt.
Zur Behebung dieses Konfliktes empfängt der Komponentenverwalter 212 bei einer oder mehreren Ausführungsformen zunächst die cloudaktualisierte Version des Digitalassets, was ein Herunterladen lediglich der modifizierten Komponente (das heißt der aktualisierten zehnten Schicht) beinhaltet. Als Nächstes bestimmt der Komponentenverwalter 212, dass der Konflikt zwischen der lokal aktualisierten Version und der cloudaktualisierten Version daher rührt, dass verschiedene Komponenten aktualisiert werden. Als solches führt der Komponentenverwalter 212 die aktualisierte Komponente aus der cloudaktualisierten Version (beispielsweise die aktualisierte zehnte Schicht) in die lokal aktualisierte Version über, die nunmehr die aktuellste Version des Digitalassets ist.
Des Weiteren sendet der Komponentenverwalter 212 die aktualisierte erste Schicht an das Cloudsynchronisierungssystem 232, damit das Cloudsynchronisierungssystem 232 über die aktuellste Version des Digitalassets verfügt. Anders gesagt, da die cloudaktualisierte Version die aktualisierte zehnte Schicht beinhaltet hat, die aktualisierte erste Schicht jedoch nicht beinhaltet hat, muss der Komponentenverwalter 212 lediglich die aktualisierte erste Schicht an das Cloudsynchronisierungssystem 232 (zusammen mit einem aktualisierten Manifest, das einen Verweis auf die aktualisierten ersten und zehnten Schichten beinhaltet) senden. Beim Senden des aktualisierten ersten Absatzes kann der Komponentenverwalter 212 mit dem Cloudsynchronisierungssystem 232 kommunizieren, um sicherzustellen, dass die lokale Version des Digitalassets zur Cloudversion des Digitalassets passt, die sodann zur neuen nachgewiesenen synchronisierten Version wird. Es sollte einsichtig sein, dass dieselben Prinzipien und Techniken auch beim Beheben von Konflikten zwischen zwei Versionen eines Digitalassets auf derselben Clientvorrichtung gelten.
Anstelle des Zusammenführens der aktuellsten Komponenten aus verschiedenen nicht synchronisierten Versionen eines Digitalassets wählt der Komponentenverwalter 212 bei alternativen Ausführungsformen die Verwendung der aktuellsten Version des Digitalassets auf Grundlage dessen, wann die Aktualisierungen an jeder Version des Digitalassets erfolgt sind. In einem anderen Fall fügt der Komponentenverwalter 212 eine Kopie einer in Konflikt stehenden Komponente zu der lokalen Version hinzu. Der Komponentenverwalter 212 fügt beim vorbeschriebenen Beispiel beispielsweise die aktualisierte zehnte Schicht vor und nach der ursprünglichen zehnten Schicht (was nachstehend noch beschrieben wird) hinzu. Bei anderen Ausführungsformen erstellt der Komponentenverwalter 212 separate Kopien des Digitalassets (das heißt separate gepackte Dateien), die jeweils eine Version der zehnten Schicht aufweisen.
In einigen Fällen tritt jedoch ein Konflikt zwischen verschiedenen Versionen derselben Komponente eines Digitalassets auf. In diesen Fällen setzt der Komponentenverwalter 212 intelligente Techniken und Verfahren zur Behebung des Konfliktes ein. Bei einer oder mehreren Ausführungsformen behebt der Komponentenverwalter 212 den Konflikt durch Erstellen einer oder mehrerer zusätzlicher Komponenten, die die in Konflikt stehenden Modifikationen beinhalten.
Demonstrationshalber sei bei einem weiteren Beispiel angenommen, dass ein Digital-PDF-Dokument (das heißt ein Digitalasset) fünf Seiten (beispielsweise Komponenten) aufweist und dass auf dieses gleichzeitig von zwei Anwendungen 226 entweder lokal oder remote zugegriffen wird. Detektiert der Komponentenverwalter 212 eine Änderung an Seite 3 seitens einer ersten Anwendung (beispielsweise einen „erste aktualisierte Seite 3“), so erstellt der Komponentenverwalter 212 eine neue Komponente in der Komponentendatenbank 214, die die erste aktualisierte Seite 3 wiedergibt. Vor dem Synchronisieren der aktualisierten Reihenseite seitens der ersten Anwendung detektiert der Komponentenverwalter 212 eine weitere Änderung auf Seite 3 seitens der zweiten Anwendung (beispielsweise eine „zweite aktualisierte Reihe 3“). Auf gleiche Weise erstellt der Komponentenverwalter 212 eine weitere neue Komponente in der Komponentendatenbank 214, die die zweite aktualisierte Reihenseite angibt.
Der Komponentenverwalter 212 behebt bei einer oder mehreren Ausführungsformen den Konflikt durch Hinzufügen der neuerstellten Komponenten zu der gepackten Datei für das Digitalasset. Demonstrationshalber ersetzt der Komponentenverwalter 212 beim vorbeschriebenen Beispiel die ursprüngliche Seite 3 sowohl durch die erste aktualisierte Seite 3 wie auch die zweite aktualisierte Seite 3. Insbesondere ersetzt der Komponentenverwalter 212 die ursprüngliche Seite 3 durch die erste aktualisierte Seite 3 und fügt daraufhin die zweite aktualisierte Seite 3 als neue Seite unmittelbar nach der ersten aktualisierten Seite 3 (beispielsweise als Reihe 4 bei einer Abwärtsbewegung über die anderen Reihen) hinzu. Alternativ hält der Komponentenverwalter 212 die ursprüngliche Seite 3 vor und fügt die erste aktualisierte Seite 3 als Seite 4 und die zweite aktualisierte Seite 3 als Seite 5 ein. Nach dem Hinzufügen der neuerzeugten Komponenten zu der gepackten Datei für das Digitalasset kann der Komponentenverwalter 212 daher das aktualisierte Digitalasset zwischen den Anwendungen und mit dem Cloudsynchronisierungssystem 232, wie vorstehend beschrieben worden ist, synchronisieren.
Indem jede Version einer in Konflikt stehenden Komponente zu einem Digitalasset hinzugefügt wird, bietet der Komponentenverwalter 212 einem Nutzer die Fähigkeit, ohne Weiteres zu detektieren, dass mehrere Versionen derselben Komponente in dem Digitalasset beinhaltet sind. Im Gegensatz hierzu duplizieren herkömmliche Dateiverwaltungssysteme oftmals das gesamte Digitalasset in Form verschiedener Versionen und überlassen es dem Nutzer herauszufinden, wo die Änderungen in jeder Version erfolgt sind und welche Änderungen die aktuellsten sind.
Bei einigen Ausführungsformen stellt der Komponentenverwalter 212 eine Benachrichtigung bereit oder zeigt auf andere Weise an, wann eine oder mehrere in Konflikt stehende Komponenten zu einem Digitalasset hinzugefügt worden sind (der Komponentenverwalter 212 nimmt beispielsweise ein Markieren, Fettdrucken, Kursivdrucken oder Ändern der Farbe einer in Konflikt stehenden Komponente vor). Zusätzlich kann der Komponentenverwalter 212 Metadaten anzeigen, die die Quelle und den Zeitstempel einer jeden der in Konflikt stehenden Komponenten angeben (der Komponentenverwalter 212 zeigt beispielsweise eine Popup-Grafik an, wenn der Nutzer einen Eingabeauswähler über jede der in Konflikt stehenden Komponenten schwebend hinwegbewegt). Auf diese Weise kann ein Nutzer einen beliebigen Fehler schnell dadurch identifizieren und ohne Weiteres berichtigen, dass eine oder mehrere der in Konflikt stehenden Komponenten entfernt, bearbeitet oder zusammengeführt werden.
Wie vorstehend beschrieben worden ist, verwaltet der Komponentenverwalter 212 Änderungen an dem Synchronisierungssystem, die als Änderungen innerhalb der Komponentendatenbank 214 gespeichert werden. Zusätzlich nimmt der Komponentenverwalter 212 zahlreiche solche Funktionen für Komponenten, die als gepackte Dateien innerhalb des Digitalassetsynchronisierungssystems 210 gespeichert sind, wahr. Weitere Details im Zusammenhang mit dem Komponentenverwalter 212 und den Funktionen werden angegeben, nachdem zusätzlicher Kontext im Zusammenhang mit einem Digitalasset, das in Form gepackter Dateien gespeichert ist, angegeben worden sind.
Ein Digitalasset, das als eine gepackte Datei, wie vorstehend spezifiziert worden ist, gespeichert ist, ist eine einzige monolithische Datei zur Darstellung eines Digitalassets. Insbesondere beinhaltet eine gepackte Datei eine Sammlung von Komponenten, die das Digitalasset bildet. Eine gepackte Datei ähnelt einem Digitalasset mit Komponenten, die in der Komponentendatenbank 214 gespeichert sind, jedoch mit Ausnahme dessen, dass die Komponenten in der gepackten Datei und eben nicht verteilt als unabhängige Dateien über die Komponentendatenbank 214 und/oder die erste Clientvorrichtung 202 hinweg abgelegt sind.
Wie ebenfalls vorstehend erwähnt worden ist, sind die als gepackte Dateien gespeicherten Digitalassets in einem Dateiverzeichnis befindlich. Als solches kann ein Nutzer eine gepackte Datei genau so sehen und mit ihr interagieren, wie er es mit einer herkömmlichen Datei gewohnt ist. Bei vielen Ausführungsformen sind die gepackten Dateien 224 in einem Dateiverzeichnis gespeichert, das durch das Digitalassetverwaltungssystem 208 und/oder das Digitalassetsynchronisierungssystem 210 überwacht wird (beispielsweise ein überwachter übergeordneter (parent) / die Wurzel bildender (root) Ordner mit Dateien und ein untergeordneter (child) / einen Teil bildender (sub) Ordner). Auf diese Weise kann das Digitalassetsynchronisierungssystem 210 Änderungen, die innerhalb des Dateiverzeichnisses auftreten, verfolgen und synchronisieren. Entsprechend beinhaltet das Digitalassetsynchronisierungssystem 210, wie in 2 gezeigt ist, einen Überwachungsagent 220.
Der Überwachungsagent 220 verfolgt und synchronisiert Dateien, die in einem überwachten Dateiverzeichnis befindlich sind und die mit dem Digitalassetsynchronisierungssystem 210 verknüpft sind. Insbesondere kommuniziert der Überwachungsagent 220 mit einem Betriebssystem der ersten Clientvorrichtung 202 wie auch mit dem Cloudsynchronisierungssystem 232 zur Detektion dessen, wann externe Änderungen an Dateien (beispielsweise gepackten und herkömmlichen Dateien) innerhalb eines überwachten Dateiverzeichnisses vorgenommen werden. Das Betriebssystem auf der ersten Clientvorrichtung 202 informiert beispielsweise den Überwachungsagent 220 darüber, dass eine gepackte Datei zu dem überwachten Dateiverzeichnis hinzugefügt worden ist. Bei einem weiteren Beispiel detektiert der Überwachungsagent 220, wenn Komponenten in einer gepackten Datei in dem Cloudsynchronisierungssystem 232 modifiziert werden. Bei einigen Ausführungsformen überwacht der Überwachungsagent 220 zudem Dateien, die außerhalb des überwachten Verzeichnisses befindlich sind, so beispielsweise eine Datei, die auf den Desktop der Clientvorrichtung eines Nutzers verschoben worden ist oder die in einen temporären Ordner außerhalb des überwachten Verzeichnisses verschoben worden ist.
Wie vorstehend erwähnt worden ist, überwacht der Überwachungsagent 220 die gepackten Dateien 224 innerhalb eines überwachten Dateiverzeichnisses zur Detektion dessen, wann sich eine oder mehrere Komponenten, die ein Digitalasset bilden, ändern. Detektiert der Überwachungsagent 220 eine Änderung an einer Komponente in einer gepackten Datei, so kommuniziert der Überwachungsagent 220 mit dem Komponentenverwalter 212 und dem Packungsverwalter 222, um die Modifikation innerhalb des Digitalassetsynchronisierungssystems 210 zu implementieren. Auf diese Weise arbeiten der Überwachungsagent 220, der Komponentenverwalter 212 und der Packungsverwalter 222 zusammen, um Änderungen an den gepackten Dateien 224 gemeinsam zu überwachen und zu implementieren.
Demonstrations- und beispielshalber alarmiert der Überwachungsagent 220 beim Detektieren von Änderungen an einer gepackten Datei eines Digitalassets den Komponentenverwalter 212 darüber, dass sich das Digitalasset und/oder die Komponente geändert hat. Detektiert der Überwachungsagent 220 beispielsweise, dass eine gepackte Datei auf dem Cloudsynchronisierungssystem 232 modifiziert worden ist, so reicht der Überwachungsagent 220 die Kennung des Digitalassets und/oder der modifizierten Komponente an den Komponentenverwalter 212 weiter, der das Manifest für das Digitalasset abruft und aktualisiert. Der Komponentenverwalter 212 leitet die modifizierte Komponente sodann an den Packungsverwalter 222 weiter, um die gepackte Datei zu aktualisieren. Der Packungsverwalter 222 wird nachstehend weiter beschrieben.
Tritt eine Modifikation an einer gepackten Datei auf, die sich bereits in dem überwachten Dateiverzeichnis befindet, so kann der Überwachungsagent 220 die Änderung detektieren und den Komponentenverwalter 212 über die Modifikation benachrichtigen. Der Komponentenverwalter 212 kann sodann mit dem Aktualisieren der gepackten Datei beginnen. Ein Nutzer öffnet beispielsweise eine gepackte Datei eines Digitalassets in einer Anwendung. Als solches greift die Anwendung auf die Komponenten des Digitalassets, die in der gepackten Datei gespeichert sind, zu und zeigt das Digitalasset als monolithische Datei an (auf ähnliche Weise wie die Anwendung auf Komponenten eines Digitalassets, die direkt in der Komponentendatenbank 214 gespeichert sind, zugreift und diese anzeigt). Des Weiteren kann die Anwendung von dem Überwachungsagent 220 die Kennung für die spezifische gepackte Datei, auf die die Anwendung zugreift, anfordern. Die Anwendung und/oder der Überwachungsagent 220 kann sodann die Kennung verwenden, um den Komponentenverwalter 212 zu benachrichtigen.
Wünscht der Nutzer eine Änderung (beispielsweise eine Bearbeitung oder Hinzufügung) einer Komponente innerhalb der Anwendung, so stellt die Anwendung die Änderung für den Überwachungsagent 220 und/oder den Komponentenverwalter 212 bereit, und der Komponentenverwalter 212 erstellt eine Kopie der Komponente in der Komponentendatenbank 214 (beispielsweise Copy-on-Write). Der Komponentenverwalter 212 wendet die Modifikationen sodann bei der Kopie der Komponente und nicht bei der Komponente selbst an. Der Komponentenverwalter 212 stellt sodann die modifizierte Komponente für den Packungsverwalter 222 bereit, damit dieser die gepackte Datei für das Digitalasset aufnimmt.
Löscht ein Nutzer eine Komponente in einer gepackten Datei, so detektiert der Überwachungsagent 220 die Löschung, und der Komponentenverwalter 212 weist den Packungsverwalter 222 an, die gepackte Datei für das Digitalasset zu aktualisieren, um die gelöschte Komponente zu entfernen / zu deaktivieren. Erstellt eine Anwendung einen neuen Satz von Komponenten, der in eine gepackte Datei aufgenommen werden soll, so detektiert der Überwachungsagent 220 die Löschung, und der Komponentenverwalter 212 erstellt zunächst unabhängige Dateien in der Komponentendatenbank 214 und weist jeder der Komponenten Kennungen zu. Sodann sendet der Komponentenverwalter 212 Kopien der Komponenten des Digitalassets an den Packungsverwalter 222, um eine gepackte Datei für das Digitalasset zu erzeugen.
Wie vorstehend erwähnt worden ist, erleichtert der Überwachungsagent 220 die Synchronisierung von Komponenten mit der ersten Clientvorrichtung 202 wie auch mit dem Cloudsynchronisierungssystem 232. Im Allgemeinen hält der Überwachungsagent 220 ein globales Register sämtlicher Digitalassets/Komponenten, die in dem überwachten Dateiverzeichnis gespeichert sind, vor (so registriert der Überwachungsagent 220 beispielsweise jede Komponente innerhalb des Digitalassetsynchronisierungssystems 210 und/oder des Digitalassetverwaltungssystems 208). Als solches steuert bzw. regelt der Überwachungsagent 220, wann die Synchronisierung für jede Komponente erfolgt. Der Überwachungsagent 220 setzt bei einigen Ausführungsformen den Komponentenverwalter 212 ein, um Komponenten zwischen der ersten Clientvorrichtung 202 und dem Cloudsynchronisierungssystem 232 zu synchronisieren.
Der Komponentenverwalter 212 erstellt wiederum beim Erstellen von neuen oder modifizierten Kopien der Komponenten, die in eine gepackte Datei aufgenommen werden sollen, bei einer oder mehreren Ausführungsformen eine Kopie der neuen oder modifizierten Komponenten innerhalb der Komponentendatenbank 214, wie vorstehend beschrieben worden ist. Mit anderen Worten, tritt eine Änderung an einer Komponente innerhalb einer gepackten Datei (beispielsweise innerhalb einer Anwendung) auf, so erstellt der Komponentenverwalter 212 eine temporäre Kopie der neuen Komponente innerhalb der Komponentendatenbank 214. Der Komponentenverwalter 212 sendet die Komponentenkopie sodann an den Packungsverwalter 222, um eine neue gepackte Datei für das Digitalasset, wie nachstehend beschrieben wird, zu erzeugen.
Des Weiteren entfernt der Komponentenverwalter 212, nachdem der Packungsverwalter 222 erfolgreich eine gepackte Datei für ein Digitalasset erstellt oder aktualisiert hat, die neue Komponente aus der Komponentendatenbank 214. Wie vorstehend erwähnt worden ist, sendet der Komponentenverwalter 212 Kopien der einen oder mehreren Komponenten an den Packungsverwalter 222, damit der Packungsverwalter 222 diese in eine gepackte Datei für ein Digitalasset aufnimmt. Als solches wird, wenn der Packungsverwalter 222 eine gepackte Datei für ein Digitalasset erstellt, eine Kopie der Komponenten für das Digitalasset in der Komponentendatenbank 214 gespeichert, während eine zweite Kopie der Komponenten in der gepackten Datei für das Digitalasset gespeichert wird. Als solches löscht der Komponentenverwalter 212 die Komponenten, die in der Komponentendatenbank 214 gespeichert sind, um zu vermeiden, dass duplizierte Kopien derselben Komponenten, die auf der ersten Clientvorrichtung 202 gespeichert sind, vorhanden sind.
Als Teil dessen, dass Kopien von Komponenten eines Digitalassets gesendet und duplizierte Komponentenkopien aus der Komponentendatenbank 214 entfernt werden, aktualisiert der Komponentenverwalter 212 zudem die Abbildung für das Digitalasset, damit diese auf die Komponenten in der gepackten Datei verweist. Anders gesagt, im Vorfeld der Entfernung der Komponenten eines Digitalassets aus der Komponentendatenbank 214, ändert der Komponentenverwalter 212 die Abbildung (beispielsweise den Pfad), die mit jeder Komponente verknüpft ist, derart, dass diese zu der gepackten Datei, die von dem Packungsverwalter 222 erstellt wird, weist. Der Komponentenverwalter 212 stellt, wenn im Weiteren Anwendungen auf das Digitalasset zugreifen, für die Anwendungen einen Zugriff auf die Komponenten, die in der gepackten Datei für das Digitalasset und eben nicht in der Komponentendatenbank 214 gespeichert sind, bereit.
Für den Packungsverwalter 222 gilt, wie vorstehend erwähnt worden ist, wiederum, dass der Packungsverwalter 222 Packungen für ein Digitalasset erzeugt, die alle Komponenten, die das Digitalasset bilden, beinhalten. Die gepackte Datei des Digitalassets ermöglicht, dass das Digitalasset als eine einzige monolithische Datei dargestellt wird. Insbesondere erstellt der Packungsverwalter 222 neue gepackte Dateien, modifiziert bestehende gepackte Dateien, ersetzt gepackte Dateien und entfernt veraltete gepackte Dateien.
Wird eine neue gepackte Datei erstellt, so empfängt der Packungsverwalter 222 bei einer oder mehreren Ausführungsformen eine Kopie von Komponenten von dem Komponentenverwalter 212 zur Aufnahme derselben in eine gepackte Datei. Der Packungsverwalter 222 packt die empfangenen Komponenten in einer gepackten Datei, die in dem überwachten Dateiverzeichnis des Digitalassetsynchronisierungssystems 210 befindlich ist. Darüber hinaus kann der Packungsverwalter 222 dem Komponentenverwalter 212 mitteilen, wann ein Digitalasset erfolgreich in eine gepackte Datei gepackt worden ist.
Bei einigen Ausführungsformen packt der Packungsverwalter 222 die Komponenten durch Komprimieren der Komponenten in eine gepackte Datei. Der Packungsverwalter 222 wendet hierbei beispielsweise einen oder mehrere Kompressionsalgorithmen an, um eine gepackte Datei für ein Digitalasset zu erzeugen, dessen Größe verringert ist und das leicht zu exportieren ist. Bei einem zusätzlichen oder alternativen Beispiel setzt der Packungsverwalter 222 einen oder mehrere Archivierungsalgorithmen ein, um Komponenten eines Digitalassets in eine gepackte Datei für das Digitalasset aufzunehmen. Bei einer oder mehreren Ausführungsformen packt der Packungsverwalter 222 die Komponenten eines Digitalassets, die von dem Komponentenverwalter 212 empfangen worden sind, in einer CCP-Datei oder einer PDF-Datei.
Empfängt der Packungsverwalter 222 eine neue Komponente, damit diese in eine bestehende gepackte Datei aufgenommen wird, so kann der Packungsverwalter 222 die Komponente zu der gepackten Datei hinzufügen. Der Packungsverwalter 222 hängt die neue Komponente beispielsweise an die anderen Komponenten in der gepackten Datei an. Bei einigen Ausführungsformen kann der Packungsverwalter 222 neue oder zusätzliche Metadaten (beispielsweise das Manifest oder andere Metadaten) an die gepackte Datei anfügen, um anzugeben, wie die neue Komponente zu den bestehenden Komponenten des Digitalassets passt.
Als Alternative dazu, die neue Komponente innerhalb der gepackten Datei anzuhängen, erzeugt der Packungsverwalter 222 eine neue gepackte Datei, um die gepackte Datei zu ersetzen. Empfängt der Packungsverwalter 222 beispielsweise eine neue Komponente, um eine bestehende Komponente zu ersetzen, so kann der Packungsverwalter 222 eine neue gepackte Datei erzeugen, die die neue Komponente enthält und die ursprüngliche Komponente ausschließt. Der Packungsverwalter 222 verwendet diese Option sodann gegebenenfalls zur Neuerzeugung der gepackten Datei, da einige Packungsverfahren, so beispielsweise die Kompression, nicht zulassen, dass der Packungsverwalter 222 eine veraltete Komponente direkt durch eine aktualisierte Version der Komponente ohne Neukompression der gepackten Datei ersetzt. Beim Erzeugen der neuen gepackten Datei kann der Packungsverwalter 222 die vorher gepackte Datei für das Digitalasset von der ersten Clientvorrichtung 202 löschen oder entfernen.
Bei Ausführungsformen, bei denen eine direkte Ersetzung möglich ist, aktualisiert der Packungsverwalter 222 die gepackte Datei, indem er eine alte Komponente direkt gegen die aktualisierte Version der Komponente austauscht. Insbesondere fügt der Packungsverwalter 222 die neue Komponente zu der gepackten Datei hinzu und zeigt gegenüber dem Komponentenverwalter 212 an, dass die neue Komponente hinzugefügt worden ist, sodass der Komponentenverwalter 212 eine beliebige Anwendung, die auf das Digitalasset zugreift, informieren kann, dass diese auf die neue Komponente zugreifen soll, wodurch der Zugriff auf die alte Komponente freigegeben wird. Sodann kann der Packungsverwalter 222 die alte Komponente löschen und die Aktualisierung der gepackten Datei für das Digitalasset (das nunmehr aktualisierte Digitalasset) beenden.
Der Packungsverwalter 222 empfängt in einigen Fällen eine Anforderung von dem Komponentenverwalter 212 dahingehend, eine Komponente aus einer gepackten Datei für ein Digitalasset zu entfernen oder zu löschen. Vor dem Löschen der Komponente bestätigt der Packungsverwalter 222, wie vorstehend beschrieben worden ist, dass auf die Komponente aktuell nicht von einer Anwendung zugegriffen wird. Bei einer oder mehreren Ausführungsformen löscht der Packungsverwalter 222, so dies als Option verfügbar ist, die Komponente direkt. Bei anderen Ausführungsformen hängt der Packungsverwalter 222, was beispielsweise bei einer komprimierten gepackten Datei der Fall ist, an die gepackte Datei Metadaten an, die anzeigen, dass diese Komponente nunmehr veraltet ist (beispielsweise wird die veraltete Komponente nicht aus der gepackten Datei entfernt, bis die gepackte Datei neuerzeugt wird). Bei zusätzlichen Ausführungsformen nimmt der Packungsverwalter 222 ein Neupacken der gepackten Datei vor (erzeugt beispielsweise eine neue gepackte Datei) und schließt dabei die entfernte Komponente aus, woraufhin der Packungsverwalter 222 die alte gepackte Datei für das Digitalasset löscht.
Wie vorstehend erwähnt worden ist, ersetzt oder löscht der Packungsverwalter 222 bei einer oder mehreren Ausführungsformen eine alte Komponente in einer gepackten Datei durch Anhängen einer neuen Komponente oder von Metadaten an eine gepackte Datei. Bei diesen Ausführungsformen hält der Packungsverwalter 222 die älteren Versionen von Komponenten und/oder Metadaten vor. Demgegenüber erfordert das Anhängen einer neuen Komponente oder neuer Metadaten an eine aktuell gepackte Datei oftmals weniger Zeit und Rechenressourcen als das Erzeugen einer neuen gepackten Datei und das Löschen der alten gepackten Datei. Zudem erfordert das Anhängen neuer Komponenten (und Metadaten) an eine gepackte Datei ohne Entfernen veralteter Komponenten zusätzlichen Speicherplatz. Nachdem der Packungsverwalter 222 verschiedene Komponenten an die gepackte Datei angehängt hat, übersteigt die Anzahl veralteter Komponenten in der gepackten Datei diejenige der Komponenten, die die aktuelle Version des Digitalassets bilden.
Als solches kann der Packungsverwalter 222 eine oder mehrere Heuristiken zur Bestimmung dessen einsetzen, ob eine neue Komponente an eine gepackte Datei angehängt werden soll oder ob eine neue gepackte Datei für ein Digitalasset erzeugt werden soll. Der Packungsverwalter 222 bestimmt beispielsweise vor oder nach dem Anhängen der neuen Komponente, ob eine neue gepackte Datei erzeugt werden soll, auf Grundlage dessen, ob die aktuell gepackte Datei eine Redundanzschwelle überschreitet. Ist dem so, so erzeugt der Packungsverwalter 222 eine neue gepackte Datei, die die neue Komponente beinhaltet und beliebige veraltete Komponenten und Metadaten ausschließt.
Die Redundanzschwelle beruht bei einer oder mehreren Ausführungsformen auf der Datengröße. Übersteigt die Datengröße veralteter Daten alter Komponenten und/oder Metadaten beispielsweise eine Schwellengröße (beispielsweise 500 kB, 1 MB oder 10 MB), so bestimmt der Packungsverwalter 222, dass eine neue gepackte Datei erstellt wird. Wird die Redundanzschwelle hingegen nicht überschritten, so hängt der Packungsverwalter 222 die neue Komponente an die bestehende gepackte Datei an. Bei einem weiteren Beispiel bestimmt der Packungsverwalter 222, wenn die Datengröße veralteter Daten ein Daten-Größe-Verhältnis oder einen Prozentanteil (wenn beispielsweise 10%, 30% oder 50% der gepackten Datei veraltete Daten sind) übersteigt, dass eine neue gepackte Datei erzeugt und die alte gepackte Datei gelöscht werden soll.
Zusätzlich und/oder alternativ beruht die Redundanzschwelle auf der Anzahl alter und/oder nützlicher Komponenten innerhalb einer gepackten Datei. Erreicht die Anzahl alter Komponenten beispielsweise eine Schwellenanzahl (beispielsweise 3, 5, 10), so bestimmt der Packungsverwalter 222, dass eine neue gepackte Datei erzeugt wird. Bei einem weiteren Beispiel bestimmt der Packungsverwalter 222, wenn das Verhältnis von veralteten zu aktuellen Komponenten ein Schwellenverhältnis oder einen Prozentanteil erreicht (wenn beispielsweise 25% oder 50% der Komponenten in der gepackten Datei veraltet sind), dass eine neue gepackte Datei erzeugt werden soll. Der Packungsverwalter 222 kann eine oder mehrere der vorgenannten Heuristiken beim Bestimmen dessen einsetzen, ob eine gepackte Datei eine oder mehrere Redundanzschwellen übersteigt (beispielsweise erfüllt).
Bei einigen Ausführungsformen bestimmt der Packungsverwalter 222, dass zunächst eine neue Komponente an eine gepackte Datei für ein Digitalasset angehängt und sodann eine neue gepackte Datei für das Digitalasset erzeugt wird. Wird auf ein Digitalasset zugegriffen, so verwendet der Packungsverwalter 222 beispielsweise eine erste (beispielsweise strengere) Redundanzschwelle, um zu bestimmen, ob eine neue Komponente für eine gepackte Datei erzeugt werden soll. Erfolgt kein Zugriff, so verwendet der Packungsverwalter 222 sodann eine zweite niedrigere (beispielsweise schwächere) Redundanzschwelle, um zu bestimmen, ob eine neue Komponente für eine gepackte Datei erzeugt werden soll, um veraltete Daten zu entfernen oder die gepackte Datei so, wie sie ist, zu belassen.
Bei einem weiteren Beispiel wartet der Packungsverwalter 222 darauf, eine neue gepackte Datei für ein Digitalasset zu erzeugen, wenn zusätzliche Rechenressourcen verfügbar sind, und zwar beispielsweise dann, wenn die erste Clientvorrichtung 202 im Leerlauf (idle) ist. Bei einem zusätzlichen Beispiel verwendet der Packungsverwalter 222 einen Plan (schedule), um gepackte Dateien für ein Digitalasset, die die Redundanzschwelle überschreiten, routinemäßig zu identifizieren, und erzeugt eine neue gepackte Datei für jene Digitalassets. Bei einem weiteren Beispiel entfernt der Packungsverwalter 222 veraltete Daten, indem neue gepackte Dateien für Digitalassets erzeugt werden, wenn eine Eingabe von einem Nutzer empfangen wird.
Es sei bemerkt, dass der Packungsverwalter 222 gepackte Dateien aus Komponenten erzeugt, die zunächst in der Komponentendatenbank 214 erstellt werden. Auf gleiche Weise kann der Packungsverwalter 222 bei einigen Ausführungsformen mit dem Komponentenverwalter 212 kommunizieren, um eine gepackte Datei für ein Digitalasset in Komponenten, die in der Komponentendatenbank 214 gespeichert sind, und umgekehrt rückzuwandeln. Ein Nutzer empfängt beispielsweise eine E-Mail, die eine gepackte Datei für ein Digitalasset beinhaltet. Beim Öffnen des Digitalassets fordern das Digitalassetverwaltungssystem 208 und das Digitalassetsynchronisierungssystem 210 den Nutzer gegebenenfalls auf, das Digitalasset innerhalb der Komponentendatenbank 214 oder als gepackte Datei innerhalb des überwachten Dateiverzeichnisses zu speichern. In Abhängigkeit von der Auswahl des Nutzers speichert der Komponentenverwalter 212 die Komponenten des Digitalassets in der Komponentendatenbank 214 oder verschiebt die gepackte Datei in das gewünschte Dateiverzeichnis. Später stellt der Nutzer gegebenenfalls eine Eingabe bereit, um die gepackte Datei in die Komponentendatenbank 214 und umgekehrt umzuwandeln. Zur Umwandlung zwischen einer gepackten Datei und einer Komponentendatenbank 214 erstellt der Packungsverwalter 222 die gepackte Datei für das Digitalasset (oder löscht diese) in Verbindung mit dem Löschen (oder Speichern) von Komponenten des Digitalassets in der Komponentendatenbank 214.
In Abhängigkeit vom Typ des Digitalassets kann das Speichern des Digitalassets in der Komponentendatenbank 214 zusätzliche Vorteile mit Blick auf den Zugriff auf das Digitalasset (beispielsweise eine höhere Zugriffsgeschwindigkeit und Echtzeitaktualisierungen an Bearbeitungen) mit sich bringen. Als solches wandeln das Digitalassetverwaltungssystem 208 und das Digitalassetsynchronisierungssystem 210 das Digitalasset bei einigen Ausführungsformen in die Komponentendatenbank 214 um, während der Nutzer das Digitalasset bearbeitet, woraufhin, wenn der Nutzer das Digitalasset speichert und/oder schließt, der Komponentenverwalter 212 die Komponenten an den Packungsverwalter 222 sendet, um eine neue gepackte Datei für das Digitalasset zu erzeugen.
Wie in 2 gezeigt ist, beinhaltet die erste Clientvorrichtung 202 die eine oder die mehreren Anwendungen 226. Die eine oder die mehreren Anwendungen 226 können mit dem Digitalassetverwaltungssystem 208 und dem Digitalassetsynchronisierungssystem 210 kommunizieren, um auf ein oder mehrere Digitalassets aus der Komponentendatenbank 214 oder den gepackten Dateien 224 zuzugreifen. Wie vorstehend erwähnt worden ist, ermöglichen die eine oder die mehreren Anwendungen 226, dass ein Nutzer ein Digitalasset erstellt, betrachtet, kopiert, modifiziert und/oder löscht. In einigen Fällen betreffen die eine oder die mehreren Anwendungen 226 einen spezifischen Typ von Digitalasset. Eine Anwendung ist beispielsweise eine textverarbeitende Anwendung, die eine Schnittstelle zu Digitaldokumenten aufweist. Bei einem anderen Beispiel ist die Anwendung eine Bildbearbeitungs-/Erstellungsanwendung, die eine Schnittstelle zu Digitalbildern aufweist.
Wie erwähnt worden ist, greifen die eine oder die mehreren Anwendungen 226 auf Digitalassets zu. Bei einem ersten Beispiel empfängt der Komponentensubverwalter von einem Nutzer eine Anforderung dahingehend, ein Digitalasset zu öffnen. Der Komponentensubverwalter kommuniziert mit dem Digitalassetverwaltungssystem 208 und dem Digitalassetsynchronisierungssystem 210, um das Digitalasset zu öffnen, darauf zuzugreifen und es anzuzeigen und um dem Nutzer zu ermöglichen, Komponenten des Digitalassets zu modifizieren, wobei der Komponentensubverwalter die Modifikationen an das Digitalassetsynchronisierungssystem 210 weiterreicht. Beim Zugreifen auf Komponenten des Digitalassets bildet der Komponentensubverwalter beispielsweise eine Schnittstelle zu dem Digitalassetsynchronisierungssystem 210, um ein Manifest für ein Digitalasset zu erhalten. Unter Verwendung des Manifests identifiziert der Komponentensubverwalter die Komponenten, die das Digitalasset bilden, die Reihenfolge, in der die Komponenten angezeigt werden, und/oder greift auf die Abbildung (beispielsweise den Pfad), wo jede Komponente gespeichert ist (beispielsweise innerhalb der Komponentendatenbank 214 oder einer der gepackten Dateien 224) zu. Beim Zugriff auf die Komponenten präsentiert (beispielsweise mittels Anzeigen) die Anwendung das Digitalasset einem Nutzer als eine einzige monolithische Datei und ermöglicht dabei dem Nutzer, individuell mit jeder Komponente des Digitalassets zu interagieren.
Wie nachstehend noch ausgeführt wird, ermöglicht eine Anwendung bei einer oder mehreren Ausführungsformen, dass ein Nutzer eine oder mehrere Komponenten eines Digitalassets modifiziert (beispielsweise erstellt, ändert oder löscht). Ist das Digitalasset beispielsweise ein Bild mit mehreren Schichten, so ermöglicht die Anwendung, dass ein Nutzer Content innerhalb einer Schicht bearbeitet. Darüber hinaus kann die Anwendung ermöglichen, dass der Nutzer Schichten hinzufügt oder entfernt. Wie vorstehend beschrieben worden ist, detektiert der Komponentenverwalter 212 des Digitalassetsynchronisierungssystems 210, wenn die Anwendung ein Digitalasset auf Grundlage einer Nutzereingabe erstellt oder modifiziert, Änderungen an den Komponenten des Digitalassets, aktualisiert das Manifest für das Digitalasset und erstellt eine oder mehrere neue Komponenten in der Komponentendatenbank 214. Sodann sendet der Komponentenverwalter 212, wenn das Digitalasset von einer gepackten Datei dargestellt wird, die neuen Komponenten an den Packungsverwalter 222, damit diese in die gepackte Datei für das Digitalasset aufgenommen werden, synchronisiert die neuen Komponenten mit dem Cloudsynchronisierungssystem 232, aktualisiert die Abbildung und entfernt die neuen Komponenten aus der Komponentendatenbank 214, wie vorstehend beschrieben worden ist.
Wie gezeigt ist, kann jede Clientvorrichtung bei einer oder mehreren Ausführungsformen mehrere Anwendungen beinhalten. Als solches ermöglicht die erste Clientvorrichtung 202, dass ein Nutzer auf dasselbe Digitalasset gleichzeitig unter Verwendung von zwei oder mehr Anwendungen zugreift. Wie vorstehend erwähnt worden ist, veranlassen das Digitalassetverwaltungssystem 208 und das Digitalassetsynchronisierungssystem 210, wenn der Nutzer die Komponente innerhalb einer Anwendung modifiziert, dass die anderen Anwendungen die modifizierte Komponente aktualisieren und anzeigen.
Auf dieselbe Weise kann, wenn das Digitalassetsynchronisierungssystem 210 eine Aktualisierung an einem Digitalasset von dem Cloudsynchronisierungssystem 232 empfängt, das Digitalassetsynchronisierungssystem 210 ermöglichen, dass eine oder mehrere Anwendungen 226 das aktualisierte Digitalasset automatisch anzeigen. Ein Nutzer betrachtet beispielsweise ein Digitalvideo unter Verwendung einer Anwendung auf der ersten Clientvorrichtung 202, während ein anderer Nutzer das Digitalvideo auf der zweiten Clientvorrichtung 204 aktualisiert. Empfängt das Digitalassetsynchronisierungssystem 210 auf der ersten Clientvorrichtung 202 die aktualisierten Komponenten (beispielsweise Videosegmente, Grafiken oder Titel), so benachrichtigt das Digitalassetsynchronisierungssystem 210 auf der ersten Clientvorrichtung 202 die Anwendung über die aktualisierten Komponenten, damit die Anwendung das aktualisierte Digitalvideo für den Nutzer der ersten Clientvorrichtung 202 bereitstellt. In einigen Fällen aktualisiert die Anwendung das Digitalvideo, wenn der Nutzer der ersten Clientvorrichtung 202 das Video ansieht, ohne dass eine zusätzliche Handlung seitens des Nutzers erforderlich wäre.
Die Elemente 210 bis 224 des Digitalassetverwaltungssystems 208 können Software, Hardware oder beides beinhalten. Die Elemente 210 bis 224 können eine oder mehrere Anweisungen beinhalten, die auf einem computerlesbaren Speichermedium gespeichert und durch Prozessoren einer oder mehrerer Rechenvorrichtungen, so beispielsweise einer Clientvorrichtung oder einer Servervorrichtung, ausführbar sind. Bei Ausführung durch den einen oder die mehreren Prozessoren können die computerausführbaren Anweisungen des Digitalassetverwaltungssystems 208 veranlassen, dass die Rechenvorrichtung / die Rechenvorrichtungen die hier beschriebenen Merkmalslernverfahren durchführt/durchführen. Alternativ können die Elemente 210 bis 224 Hardware, so beispielsweise eine Spezialzweckverarbeitungsvorrichtung, beinhalten, um eine bestimmte Funktion oder eine Gruppe von Funktionen wahrzunehmen. Alternativ können die Elemente 210 bis 224 des Digitalassetverwaltungssystems 208 eine Kombination von computerausführbaren Anweisungen und Hardware beinhalten.
Die Elemente 210 bis 224 des Digitalassetverwaltungssystems 208 können beispielsweise als ein oder mehrere Betriebssysteme, als ein oder mehrere eigenständige (stand-alone) Anwendungen, als ein oder mehrere Module einer Anwendung, als ein oder mehrere Plug-ins, als ein oder mehrere Bibliotheksfunktionen oder Funktionen, die von anderen Anwendungen aufgerufen werden können, und/oder als Cloudrechenmodell implementiert sein. Damit können die Elemente 210 bis 224 als eigenständige (stand-alone) Anwendung, so beispielsweise als Desktop- oder Mobilanwendung, implementiert sein. Des Weiteren können die Elemente 210 bis 224 als eine oder mehrere webbasierte Anwendungen, die auf einem Remote-Server gehostet sind, implementiert sein. Die Elemente 210 bis 224 können zudem in einer Suite von Mobilvorrichtungsanwendungen oder „Apps“ implementiert sein. Illustrationshalber können die Elemente 210 bis 224 in einer Anwendung implementiert sein, darunter unter anderem in der Software ADOBE CREATIVE CLOUD. „ADOBE“ und „CREATIVE CLOUD“ sind entweder eingetragene Marken oder Marken von Adobe Systems Incorporated in den Vereinigten Staaten und/oder anderen Ländern.
2 zeigt zudem ein Cloudsynchronisierungssystem 232, das eine Remote-Komponentendatenbank 234 beinhaltet. Wie gezeigt ist, ist das Cloudsynchronisierungssystem 232 auf einer Servervorrichtung 230 befindlich. Es sollte jedoch einsichtig sein, dass das Cloudsynchronisierungssystem 232 auch über mehrere Servervorrichtungen hinweg verteilt sein kann. Die Remote-Komponentendatenbank 234 befindet sich beispielsweise auf einer oder mehreren Servervorrichtungen, die von dem Cloudsynchronisierungssystem 232 getrennt sind.
Das Cloudsynchronisierungssystem 232 speichert allgemein Remote-Kopien von Komponenten von Digitalassets, darunter Komponenten, die vorherigen Versionen von Digitalassets entsprechen. Auf diese Weise werden bei einer vollständigen Synchronisierung Digitalassets, die auf einer Clientvorrichtung gespeichert sind, auch in der Remote-Komponentendatenbank 234 gespeichert. Bei einigen Ausführungsformen teilt das Cloudsynchronisierungssystem 232 jeder Komponente, die in der Remote-Komponentendatenbank 234 gespeichert ist, eine Cloudkennung zu. Das Cloudsynchronisierungssystem 232 dient zudem als gemeinsamer Hub bzw. als gemeinsame Zentrale, um das Digitalasset zwischen Clientvorrichtungen (beispielsweise zwischen der ersten Clientvorrichtung 202 und der zweiten Clientvorrichtung 204) zu synchronisieren. Bei einigen Ausführungsformen stellt das Cloudsynchronisierungssystem 232 zudem Onlinedienste bereit, so beispielsweise Onlineanwendungen, die ermöglichen, dass ein Nutzer Digitalassets betrachtet und bearbeitet.
Darüber hinaus beinhaltet die Remote-Komponentendatenbank 234 oftmals mehr Digitalassets, als auf einer Clientvorrichtung zu finden sind. Clientvorrichtungen synchronisieren beispielsweise oftmals nicht die gesamte Digitalassetsammlung eines Nutzers lokal. Darüber hinaus weist die Servervorrichtung 230 typischerweise eine größere Speicherkapazität als eine Clientvorrichtung, insbesondere als mobile Clientvorrichtungen, auf, und kann als solches mehr Digitalassets und Versionen von Digitalassets als die Clientvorrichtung speichern. Auf diese Weise kann das Cloudsynchronisierungssystem 232 auf Anfrage einige oder alle vorherigen Versionen eines Digitalassets für eine Clientvorrichtung bereitstellen.
Ein Unterschied zwischen dem Cloudsynchronisierungssystem 232 und einem Synchronisierungssystem 210 auf einer Clientvorrichtung besteht darin, dass das Cloudsynchronisierungssystem 232 Digitalassets nicht als gepackte Dateien speichern muss. Im Allgemeinen interagiert ein Nutzer nicht direkt mit Digitalassets auf dem Cloudsynchronisierungssystem 232. Als solches kann das Cloudsynchronisierungssystem 232 Digitalassets (darunter vorherige Versionen) innerhalb der Remote-Komponentendatenbank 234 speichern. Des Weiteren kann das Cloudsynchronisierungssystem 232 Digitalassets, die zu verschiedenen Nutzern gehören, in derselben Remote-Komponentendatenbank 234 speichern, solange das Cloudsynchronisierungssystem 232 geeignete Genehmigungen und Nutzerautorisierungen für jedes Digitalasset vorhält.
Bei einigen Ausführungsformen stellt das Cloudsynchronisierungssystem 232 für einen Nutzer einen Remote-Zugriff auf Digitalassets, beispielsweise über einen Webbrowser, bereit. Wie vorstehend erwähnt worden ist, stellt das Cloudsynchronisierungssystem 232 Onlinedienste, so beispielsweise Onlineanwendungen, die ermöglichen, dass ein Nutzer Digitalassets betrachtet und bearbeitet, bereit. Bei zusätzlichen Ausführungsformen stellt das Cloudsynchronisierungssystem 232 ein Onlinedateiverzeichnis eines Digitalassets des Nutzers bereit, das zu allen Digitalassets in dem überwachten Dateiverzeichnis auf der ersten Clientvorrichtung 202 und/oder der zweiten Clientvorrichtung 204 passt oder diese beinhaltet. Bei den vorliegenden Ausführungsformen muss das Cloudsynchronisierungssystem 232 keine gepackte Datei für ein Digitalasset wie auf der Clientvorrichtung erstellen, sondern kann das Digitalasset für einen Nutzer symbolisch derart darstellen, dass das Digitalasset als eine einzige monolithische Datei innerhalb des Onlinedateiverzeichnisses erscheint.
Des Weiteren kann das Cloudsynchronisierungssystem 232 dem Nutzer eine oder mehrere vorherige Versionen des Digitalassets in Verbindung mit dem Digitalasset präsentieren. Auf ähnliche Weise kann das Cloudsynchronisierungssystem 232 eine Liste aller Digitalassets, die in der Remote-Komponentendatenbank 234 beinhaltet sind, darunter auch vorherige Versionen, anzeigen.
Wie vorstehend beschrieben worden ist, zeigt 2 ein Framework eines Synchronisierungssystems 210 (mit einem Digitalassetverwaltungssystem 208) mit Bezug auf eine gepackte Datei für ein Digitalasset. 3 bis 12 zeigen exemplarische Implementierungen und Betriebsvorgänge des Digitalassetverwaltungssystems 208 und des Digitalassetsynchronisierungssystems 210 beim Erstellen, Aktualisieren, Öffnen und Entfernen einer gepackten Datei für ein Digitalasset. Bei einer oder mehreren Ausführungsformen betreffen 3 bis 12 das Digitalassetsynchronisierungssystem 208, das eine Anwendungsprogrammierschnittstelle (API) für den Komponentenverwalter 212 (beispielsweise unter Verwendung von DCX) und den Überwachungsagent 220 (beispielsweise über CoreSync) bereitstellt. Insbesondere zeigen 3 bis 5 das Digitalassetverwaltungssystem 208 und das Digitalassetsynchronisierungssystem 210 beim Erstellen einer neuen gepackten Datei für ein Digitalasset; 6 bis 8 zeigen das Digitalassetverwaltungssystem 208 und das Digitalassetsynchronisierungssystem 210 beim Aktualisieren einer gepackten Datei für ein Digitalasset; 9 zeigt das Digitalassetverwaltungssystem 208 und das Digitalassetsynchronisierungssystem 210 beim Öffnen einer gepackten Datei eines Digitalassets; und 10 bis 12 zeigen das Digitalassetverwaltungssystem 208 und das Digitalassetsynchronisierungssystem 210 beim Entfernen einer gepackten Datei eines Digitalassets. Der Kürze halber verweist die Beschreibung im Zusammenhang mit 3 bis 12 bei Bedarf auf 2, wo Handlungen, Schritte, Vorgänge und/oder Verfahren, die bei dem Digitalassetsynchronisierungssystem und/oder dem Cloudspeichersystem auftreten, detaillierter beschrieben sind.
Jede der 3 bis 12 beinhaltet eine Clientvorrichtung 202, die das Digitalassetverwaltungssystem 208 und das Digitalassetsynchronisierungssystem 210 (oder einfach das „Synchronisierungssystem 210“) beinhaltet. Die Clientvorrichtung 202 kann eine Ausführungsform der ersten Clientvorrichtung 202 sein, die anhand 2 beschrieben worden ist. Auf gleiche Weise können das Digitalassetverwaltungssystem 208 und das Digitalassetsynchronisierungssystem 210 jeweils eine oder mehrere Ausführungsformen des Digitalassetverwaltungssystems 208 und des Digitalassetsynchronisierungssystems 210, die vorstehend beschrieben worden sind, verkörpern. Das Digitalassetsynchronisierungssystem 210 von 3 bis 12 beinhaltet beispielsweise jeweils einen Komponentenverwalter 212 und einen Überwachungsagent 220, wie vorstehend beschrieben worden ist.
Darüber hinaus zeigen 4, 7 und 11 zudem eine Anwendung 226 auf der Clientvorrichtung 202, die die eine oder die mehreren Anwendungen 226 gemäß vorstehender Beschreibung verkörpert. Zudem zeigen 3 bis 8 sowie 10 bis 12 eine Servervorrichtung 230, die ein Cloudsynchronisierungssystem 232 hostet. Die Servervorrichtung 230 und das Cloudsynchronisierungssystem 232 können jeweils eine oder mehrere Ausführungsformen der Servervorrichtung 230 und des Cloudsynchronisierungssystems 232, wie vorstehend beschrieben worden ist, verkörpern.
Wie erwähnt worden ist, zeigen 3 bis 5 das Digitalassetsynchronisierungssystem 210 beim Erstellen einer neuen gepackten Datei für ein Digitalasset. Insbesondere zeigt 3 ein Sequenzdiagramm des Digitalassetsynchronisierungssystems 210 beim Erstellen einer neuen gepackten Datei für ein Digitalasset beim Detektieren eines neuen Digitalassets. Das Digitalassetsynchronisierungssystem 210 detektiert ein neues Digitalasset, das in einem überwachten Dateiverzeichnis abgelegt ist.
Wie in 3 gezeigt ist, detektiert der Überwachungsagent 220 des Digitalassetsynchronisierungssystems 210 ein neues Digitalasset, siehe 302. Ein Nutzer verschiebt das Digitalasset beispielsweise von einem nichtüberwachten Dateiverzeichnis auf der Clientvorrichtung 202 in das überwachte Dateiverzeichnis. Bei einem weiteren Beispiel speichert ein Nutzer ein Digitalasset, das in einer E-Mail-Mitteilung empfangen worden ist, in dem überwachten Dateiverzeichnis, oder der Nutzer speichert auf andere Weise ein Digitalasset, das aus dem Internet heruntergeladen worden ist, in dem überwachten Dateiverzeichnis. Bei einem zusätzlichen Beispiel speichert ein Nutzer mittels einer Anwendung, die keine Schnittstelle zu Komponenten aufweist (die Anwendung ist beispielsweise nicht dafür ausgelegt, auf Komponenten eines Digitalassets zuzugreifen und diese als eine einzige Datei anzuzeigen), ein Digitalasset innerhalb des überwachten Dateiverzeichnisses. Bei jedem dieser Beispiele detektiert der Überwachungsagent 220 das neue Digitalasset, wenn das Digitalasset in das überwachte Dateiverzeichnis verschoben oder dort gespeichert wird.
Im Allgemeinen detektiert der Überwachungsagent 220, wann ein neues Digitalasset zu dem überwachten Dateiverzeichnis hinzugefügt wird. Der Überwachungsagent 220 detektiert hingegen nicht, ob das Digitalasset eine Komponenten beinhaltende gepackte Datei ist oder eine herkömmliche Datei ist. Das Digitalasset ist beispielsweise ein neuhinzugefügtes Digitalasset, wie vorstehend erwähnt worden ist. Bei einem weiteren Beispiel ist das Digitalasset eine neuerstellte gepackte Datei aus Komponenten. Als solches stellt der Überwachungsagent 220 alle detektierten neuen oder aktualisierten Dateien für den Komponentenverwalter 212 bereit, der bestimmt, ob das Digitalasset eine gepackte Datei ist.
Wie erwähnt worden ist, berichtet, siehe 304, der Überwachungsagent 220 beim Detektieren eines neuen Digitalassets dem Komponentenverwalter 212 von dem detektierten Digitalasset. Das Berichten von dem Digitalasset beinhaltet bei einigen Ausführungsformen das Bereitstellen der Dateiabbildung des neuhinzugefügten Digitalassets für den Komponentenverwalter 212, damit der Komponentenverwalter 212 auf das Digitalasset zugreifen kann.
Der Komponentenverwalter 212 verifiziert sodann, siehe 306, dass das Digitalasset eine gepackte Datei ist. Der Komponentenverwalter 212 identifiziert sodann beispielsweise, dass das Digitalasset eine Sammlung von Komponenten beinhaltet. Bei einem weiteren Beispiel identifiziert der Komponentenverwalter 212 Metadaten, die mit dem Digitalasset verknüpft sind, wodurch angezeigt wird, dass das Digitalasset eine gepackte Datei ist. Alternativ bestimmt der Komponentenverwalter 212, dass das Digitalasset eine herkömmliche Datei ist, die keine gespeicherten Komponenten enthält. Bei einigen Ausführungsformen bestimmt der Komponentenverwalter 212, dass das Digitalasset eine gepackte Datei ist, auf Grundlage der Dateierweiterung des Digitalassets (beispielsweise .ccp, .zip oder .pdf).
Beim Bestimmen dessen, dass das Digitalasset eine gepackte Datei ist, speichert der Komponentenverwalter 212, siehe 308, die Komponenten des Digitalassets in der Komponentendatenbank. Als Teil des Speicherns des Digitalassets weist der Komponentenverwalter 212 dem Digitalasset eine Aufzeichnungskennung (record id) zu. Zusätzlich verwendet der Komponentenverwalter 212 bei einer oder mehreren Ausführungsformen Metadaten aus der gepackten Datei zur Speicherung von Kennungen für die Komponenten des Digitalassets. Der Komponentenverwalter 212 überträgt die Kennungen aus einem Manifest, das in der gepackten Datei beinhaltet ist, in die Komponentendatenbank. Alternativ erzeugt der Komponentenverwalter 212 neue Kennungen für jede der Komponenten des Digitalassets, die in der gepackten Datei beinhaltet sind.
Unter Verwendung der Kennungen, die mit den Komponenten des Digitalassets verknüpft sind, erzeugt der Komponentenverwalter 212 bei einigen Ausführungsformen ein Manifest und eine entsprechende Abbildung für das Digitalasset. Der Komponentenverwalter 212 bildet beispielsweise den Ort einer jeden Komponente zurück auf die gepackte Datei ab. Durch Erzeugen eines neuen Manifests und einer entsprechenden Abbildung kann der Komponentenverwalter 212 zusätzliche Änderungen an dem Digitalasset, wie vorstehend beschrieben worden ist, verfolgen und implementieren. Bei alternativen Ausführungsformen empfängt der Komponentenverwalter 212 das Manifest von der gepackten Datei und aktualisiert das empfangene Manifest derart, dass auf die neue Abbildung (beispielsweise den Pfad) der Komponenten verwiesen wird.
Nach dem Speichern der Komponenten des Digitalassets innerhalb der Komponentendatenbank stellt der Komponentenverwalter 212 die Kennung (beispielsweise die Aufzeichnungskennung) für das Digitalasset bereit, siehe 310. Obwohl dies nicht gezeigt ist, kann, sobald der Komponentenverwalter 212 die Kennung bereitstellt, der Überwachungsagent 220 bei zukünftigen Aufrufen des Komponentenverwalters 212 auf die Aufzeichnungskennung zugreifen und diese nutzen. Wie nachstehend noch beschrieben wird, reicht der Überwachungsagent 220 die Aufzeichnungskennung an den Komponentenverwalter 212 beim Detektieren einer Änderung in dem Digitalasset weiter.
Der Komponentenverwalter 212 kann zudem Komponenten des Digitalassets mit dem Cloudsynchronisierungssystem 232 optional synchronisieren, siehe 312. Insbesondere sendet der Komponentenverwalter 212 das Manifest und die Komponenten des Digitalassets an das Cloudsynchronisierungssystem 232. Wie vorstehend anhand 2 beschrieben worden ist, kann das Digitalassetsynchronisierungssystem 210 Komponenten mit dem Cloudsynchronisierungssystem 232, das Remote-Kopien der Digitalassets, darunter mehrere Versionen eines Digitalassets, speichert, synchronisieren.
9 zeigt ein Sequenzdiagramm des Digitalassetsynchronisierungssystems 210 beim Erstellen einer neuen gepackten Datei für ein Digitalasset auf der Clientvorrichtung 202. Ein Nutzer erstellt beispielsweise innerhalb der Anwendung 226 auf der Clientvorrichtung 202 ein neues Digitalasset, das das Digitalassetsynchronisierungssystem 210 als gepackte Datei speichert.
Wie gezeigt ist, erstellt die Anwendung 226 ein neues Digitalasset, siehe 402, das Komponenten, die das Digitalasset bilden, verwendet. In Reaktion darauf, dass der Nutzer beispielsweise ein neues Digitalbild (das heißt ein Digitalasset) anfordert, stellt die Anwendung 226 für den Nutzer eine leere Leinwand bereit, die aus einer Hintergrundschicht (das heißt einer Komponente), einer Vordergrundschicht sowie einer oder mehreren verborgenen Schichten, die Metadaten für das Digitalbild enthalten, besteht.
In Verbindung damit, dass die Anwendung 226 eine Sammlung von Komponenten für ein neues Digitalasset erstellt, führt die Anwendung 226 einen Handshake mit dem Komponentenverwalter 212 durch, siehe 404, und weist den neuen Komponenten Kennungen zu. Wie vorstehend beschrieben worden ist, teilt der Komponentenverwalter 212 Kennungen für die neuen Komponenten zu und registriert diese. Der Handshake als solcher beinhaltet, dass der Komponentenverwalter 212 eine Aufzeichnungskennung für das Digitalasset erstellt und das neue Digitalasset speichert. Auf diese Weise beinhaltet der Handshake, dass der Komponentenverwalter 212 Kennungen für die neuen Komponenten zuteilt.
Bei einer oder mehreren Ausführungsformen verwendet das Digitalassetsynchronisierungssystem 210 eine oder mehrere Inter-Prozess-Kommunikationen (IPC), so beispielsweise eine VULCAN-RPC-Anforderung (Remote Process Call RPC), um den Handshake zwischen der Anwendung 226 und dem Digitalassetsynchronisierungssystem 210 zu vereinfachen. Bei einigen Ausführungsformen muss der Handshake erfolgreich vollzogen sein, bevor das Digitalassetsynchronisierungssystem 210 zusätzliche Aktionen im Zusammenhang mit dem Digitalasset, so beispielsweise das Speichern der neuen Komponenten in der Komponentendatenbank oder das Synchronisieren der neuen Komponenten, ausführt.
Ist der Handshake vollzogen, so speichert der Komponentenverwalter 212 die neuen Komponenten des Digitalassets in der Komponentendatenbank, siehe 406. Der Komponentenverwalter 212 empfängt beispielsweise die neuen Komponenten von der Anwendung 226, verknüpft die neuen Komponenten mit den zugeteilten Kennungen, bildet die neuen Komponenten in der Komponentendatenbank ab und registriert diese. Wie vorstehend beschrieben worden ist, kann der Komponentenverwalter 212 auch ein neues Manifest für das Digitalasset erstellen, das die Komponenten und die Abbildung der Komponenten beinhaltet.
Der Komponentenverwalter 212 kann zudem optional die neuen Komponenten des Digitalassets mit dem Cloudsynchronisierungssystem 232 synchronisieren, siehe 408. Insbesondere sendet der Komponentenverwalter 212 das Manifest und die neuen Komponenten des Digitalassets an das Cloudsynchronisierungssystem 232. Wie vorstehend in Verbindung mit 2 beschrieben worden ist, synchronisiert das Digitalassetsynchronisierungssystem 210 neue Komponenten mit dem Cloudsynchronisierungssystem 232 kurz nach dem Speichern der neuen Komponenten, um sicherzustellen, dass die neuen Komponenten über ein sicheres Back-up verfügen.
Wie in 4 gezeigt ist, erstellt, siehe 410, der Komponentenverwalter 212 eine gepackte Datei des Digitalassets. Insbesondere sendet, wie vorstehend anhand 2 beschrieben worden ist, der Komponentenverwalter 212 Kopien der Komponente an einen Packungsverwalter, der die gepackte Datei erzeugt. Der Einfachheit halber ist der Packungsverwalter in 4 bis 12 nicht gezeigt, wobei jedoch die Funktionen des Packungsverwalters in den gezeigten Komponentenverwalter 212 integriert sind.
Der Komponentenverwalter 212 speichert, siehe 412, sodann die neuerstellte gepackte Datei für das Digitalasset. Nachdem die gepackte Datei, wie vorstehend detailliert beschrieben worden ist, erzeugt worden ist, aktualisiert der Komponentenverwalter 212 die Abbildung für den Verweis auf die neuen Komponenten in der gepackten Datei und entfernt die Komponenten aus der Komponentendatenbank. Der Überwachungsagent 220 überwacht sodann das neugespeicherte Digitalasset in dem überwachten Dateiverzeichnis und berichtet dem Komponentenverwalter 212, wann eine Änderung an den Digitalassets auftritt, wie vorstehend beschrieben worden ist.
4 ist im Übrigen anhand dessen beschrieben, dass ein Nutzer in der Anwendung 226 ein neues Digitalasset erstellt, das Komponenten aufweist. Die in 4 bereitgestellten Aktionen sind zudem anwendbar, wenn ein neues Digitalasset ein vorheriges Digitalasset überschreibt. Insbesondere wenn ein neues Digitalasset ein vorheriges Digitalasset überschreibt, erkennt das Digitalassetsynchronisierungssystem 210 das neue Digitalasset als neu und folgt den vorstehend angegebenen Aktionen. Des Weiteren löscht das Digitalassetsynchronisierungssystem 210 das überschriebene Digitalasset, was nachstehend anhand 10 bis 12 noch beschrieben wird.
5 zeigt ein Sequenzdiagramm des Digitalassetsynchronisierungssystems 210 beim Erzeugen einer neuen gepackten Datei für ein Digitalasset auf Grundlage des Empfangs von Komponenten des Digitalassets von dem Cloudsynchronisierungssystem 232. Ein Synchronisierungssystem auf einer anderen Clientvorrichtung erstellt und aktualisiert beispielsweise ein Digitalasset für das Cloudsynchronisierungssystem 232, das sodann mit der Clientvorrichtung 202 synchronisiert wird.
Wie gezeigt ist, zeigt das Cloudsynchronisierungssystem 232 gegenüber dem Digitalassetsynchronisierungssystem 210 neue Komponenten eines Digitalassets über den Überwachungsagent 220 an, siehe 502. Das Cloudsynchronisierungssystem 232 stellt für den Überwachungsagent 220 beispielsweise eine Nachricht bereit, die angibt, dass ein neues Digitalasset auf dem Cloudsynchronisierungssystem 232 gespeichert ist. Alternativ kommuniziert der Überwachungsagent 220 periodisch mit dem Cloudsynchronisierungssystem 232, um über Änderungen zu berichten und aufzudecken, wann neue oder modifizierte Digitalassets auf dem Cloudsynchronisierungssystem 232 zur Synchronisierung mit der Clientvorrichtung 202 bereitstehen.
Beim Detektieren des neuen Digitalassets berichtet der Überwachungsagent 220 dem Komponentenverwalter 212 über die neuen Komponenten, wie vorstehend beschrieben worden ist, siehe 504. Wie zudem vorstehend beschrieben worden ist, teilt der Komponentenverwalter 212 Kennungen 506 für die neuen Komponenten zu und teilt zudem eine Kennung (beispielsweise eine Aufzeichnungskennung) für das Digitalasset zu, die der Komponentenverwalter 212 jeweils für den Überwachungsagent 220 bereitstellen kann.
Der Komponentenverwalter 212 synchronisiert, siehe 508, sich sodann mit dem Cloudsynchronisierungssystem 232, um die neuen Komponenten zu empfangen. Das Cloudsynchronisierungssystem 232 überträgt beispielsweise die neuen Komponenten des Digitalassets (mittels Pushing) an den Komponentenverwalter 212. Bei einem alternativen Beispiel informiert das Cloudsynchronisierungssystem 232 den Komponentenverwalter 212 über das neue Digitalasset, und der Komponentenverwalter 212 überträgt mittels Pulling die Komponenten von dem Cloudsynchronisierungssystem 232 und speichert die Komponenten temporär in der Komponentendatenbank.
Nach dem Empfangen der neuen Komponenten speichert, siehe 510, der Komponentenverwalter 212 die neuen Komponenten des Digitalassets in der Komponentendatenbank unter Verwendung der zugeteilten Kennungen. Der Komponentenverwalter 212 erstellt zudem ein Manifest für das Digitalasset, wie vorstehend beschrieben worden ist. Zusätzlich erstellt, siehe 512, der Komponentenverwalter 212 (in Verbindung mit einem Packungsverwalter) eine gepackte Datei für das Digitalasset, wie vorstehend erläutert worden ist. Des Weiteren speichert, siehe 514, der Komponentenverwalter 212, wie bereits beschrieben worden ist, die neuerstellte gepackte Datei für das Digitalasset.
6 zeigt ein Sequenzdiagramm des Digitalassetsynchronisierungssystems 210 beim Aktualisieren einer gepackten Datei auf der Clientvorrichtung 202. Im Allgemeinen beschreibt 6 das Ersetzen einer gepackten Datei durch eine neue Kopie der gepackten Datei. Ein Nutzer, der mit einer Anwendung interagiert, ändert beispielsweise eine oder mehrere Komponenten eines Digitalassets, wodurch ausgelöst wird, dass das Digitalassetsynchronisierungssystem 210 eine neue gepackte Datei für das Digitalasset erzeugt.
Insbesondere zeigt 6 den Überwachungsagent 220 beim Detektieren, siehe 602, einer Änderung in einer gepackten Datei für ein Digitalasset. Der Überwachungsagent 220 detektiert beispielsweise, dass eine Anwendung auf das als gepackte Datei gespeicherte Digitalasset zugreift. Bei einem weiteren Beispiel detektiert der Überwachungsagent 220, dass ein Nutzer eine oder mehrere Komponenten innerhalb der gepackten Datei für das Digitalasset aktualisiert (beispielsweise hinzufügt, bearbeitet, entfernt). Bei einigen Ausführungsformen detektiert der Komponentenverwalter 212, wie vorstehend beschrieben worden ist, eine Änderung an einer oder mehreren Komponenten innerhalb der gepackten Datei für das Digitalasset.
Wie vorstehend erwähnt worden ist, stellt der Komponentenverwalter 212 nach dem Erstellen einer neuen gepackten Datei für ein Digitalasset eine oder mehrere Kennungen für den Überwachungsagent 220 bereit. Sodann verwendet der Überwachungsagent 220, wenn er dem Komponentenverwalter 212 von einem modifizierten Digitalasset berichtet, die Kennung, die dem modifizierten Digitalasset entspricht. Illustrationshalber zeigt 6 den Überwachungsagent 220 beim Nachschlagen, siehe 604, der Kennung für das Digitalasset während des Detektierens einer Änderung in der gepackten Datei für das Digitalasset. Der Überwachungsagent 220 verwendet sodann die Kennung, um dem Komponentenverwalter 212 von dem modifizierten Digitalasset zu berichten, siehe 606.
Wie gezeigt ist, verifiziert, siehe 608, der Komponentenverwalter 212 die Modifikation an dem Digitalasset. Insbesondere verifiziert der Komponentenverwalter 212, dass eine Änderung an einer oder mehreren Komponenten innerhalb der gepackten Datei für das Digitalasset vorgenommen worden ist. In einigen Fällen zeigt der Überwachungsagent 220 eine Änderung an der gepackten Datei auf Grundlage des Komponentenverwalters 212, der die gepackte Datei vorher erstellt oder geschrieben hat, an. In diesen Fällen überspringt der Komponentenverwalter 212 die Benachrichtigung seitens des Überwachungsagenten 220, da sich die gepackte Datei für das Digitalasset eigentlich nicht geändert hat.
Beim Verifizieren dessen, dass sich eine oder mehrere Komponenten der gepackten Datei für das Digitalasset geändert haben (wenn beispielsweise ein anderer Agierender als der Komponentenverwalter 212 die Änderung implementiert hat), muss der Komponentenverwalter 212 die gepackte Datei innerhalb des Digitalassetsynchronisierungssystems 210 synchronisieren. Insbesondere zeigt die dargestellte Ausführungsform, dass der Komponentenverwalter 212 eine Aktualisierung der gepackten Datei für das Digitalasset anfordert, siehe 610. Bei alternativen Ausführungsformen stellt der Komponentenverwalter 212 für den Überwachungsagent 220 eine Anforderung dahingehend, die Aktualisierung zu koordinieren (schedule), bereit. Der Überwachungsagent 220 verfügt beispielsweise, wie vorstehend beschrieben worden ist, über globales Wissen im Zusammenhang mit allen anhängigen Synchronisierungsvorgängen (sowohl innerhalb des Digitalassetsynchronisierungssystems 210 wie auch in dem Cloudsynchronisierungssystem 232). Als solches verschiebt der Komponentenverwalter 212 bei diesen alternativen Ausführungsformen das Koordinieren der Aktualisierungen an der gepackten Datei für das Asset an den Überwachungsagent 220.
Der Überwachungsagent 220 stellt, wenn er zum Aktualisieren der gepackten Datei für das Digitalasset bereit ist, die Digitalassetkennung für den Komponentenverwalter 212 bereit, siehe 612, wodurch der Packungsaktualisierungsprozess initiiert wird. Bei einer oder mehreren Ausführungsformen stellt der Überwachungsagent 220 zudem die Abbildung (beispielsweise den Pfad), wo das Digitalasset in dem überwachten Dateiverzeichnis befindlich ist, bereit. Der Komponentenverwalter 212 verwendet die Kennung dafür, das Digitalasset zu identifizieren, sowie dafür, welche Komponenten innerhalb der gepackten Datei aktualisiert worden sind.
Wie gezeigt ist, synchronisiert der Komponentenverwalter 212 bei einigen Ausführungsformen die modifizierten Komponenten mit dem Cloudsynchronisierungssystem 232, siehe 614, bevor ein Aktualisieren der gepackten Datei für das Digitalasset erfolgt. Darüber hinaus aktualisiert, siehe 616, der Komponentenverwalter 212 (in Verbindung mit einem Packungsverwalter) die gepackte Datei, wie vorstehend erläutert worden ist. Des Weiteren speichert, siehe 618, wie vorstehend beschrieben worden ist, der Komponentenverwalter 212 die aktualisierte gepackte Datei für das Digitalasset. Der Komponentenverwalter 212 und/oder ein Packungsverwalter hängen die gepackte Datei für das Digitalasset beispielsweise an oder erzeugen diese neu, wie vorstehend detailliert anhand 2 beschrieben worden ist.
Bei einigen Ausführungsformen bestimmt der Überwachungsagent 220 beim Aktualisieren der Komponenten in dem Komponentenverwalter 212, dass zusätzliche Änderungen an dem Digitalasset in dem Cloudsynchronisierungssystem 232 verfügbar sind. Beim Synchronisieren mit dem Cloudsynchronisierungssystem 232 bestimmt der Komponentenverwalter 212 beispielsweise, dass zusätzliche Modifikationen für das Digitalasset auf einer anderen Clientvorrichtung aufgetreten sind. Als solches empfängt das Digitalassetsynchronisierungssystem 210 die aktualisierten Komponenten und wiederholt den Prozess des Aktualisierens der gepackten Datei, wie hier beschrieben wird.
7 zeigt ein Sequenzdiagramm des Digitalassetsynchronisierungssystems 210 beim Aktualisieren einer gepackten Datei, wenn die Anwendung 226 eine Komponente innerhalb der gepackten Datei modifiziert. Ein Nutzer bearbeitet beispielsweise das Digitalasset mittels der Anwendung 226, was bewirkt, dass die Anwendung eine oder mehrere Komponenten der gepackten Datei für das Digitalasset modifiziert.
Wie gezeigt ist, zeigt die Anwendung 226 die Komponenten eines Digitalassets als eine monolithische Datei an, siehe 702. Die Anwendung 226 lokalisiert beispielsweise die Komponenten des Digitalassets innerhalb der gepackten Datei und greift auf diese zu, um das Digitalasset innerhalb der Anwendung 226, wie vorstehend beschrieben worden ist, anzuzeigen. Als solches kann die Anwendung 226 die Komponenten des Digitalassets derart anzeigen, dass das Digitalasset als eine einzige Datei erscheint.
Als Nächstes modifiziert, siehe 704, die Anwendung 226, wie dargestellt ist, eine Komponente des Digitalassets. In Reaktion auf eine Nutzereingabe nimmt die Anwendung 226 beispielsweise ein Hinzufügen, Ändern oder Entfernen einer Komponente des Digitalassets vor. Zusätzlich kann die Anwendung 226 die Änderung gegenüber dem Komponentenverwalter 212, wie gezeigt ist, anzeigen. Wie vorstehend beschrieben worden ist, erstellt der Komponentenverwalter 212, wenn eine Komponente geändert oder hinzugefügt wird, eine neue Kopie der Komponente, die die Modifikationen beinhaltet, und speichert die neue Komponente vorübergehend in der Komponentendatenbank.
Der Komponentenverwalter 212 gibt sodann, wie in 7 gezeigt ist, die modifizierte Komponente an, siehe 706, und modifiziert, siehe 708, die gepackte Datei für das Digitalasset, wie vorstehend beschrieben worden ist. Zusätzlich speichert, siehe 710, der Komponentenverwalter 212 die modifizierte gepackte Datei für das Digitalasset. Bei einigen Ausführungsformen detektiert der Überwachungsagent 220, dass sich ein Digitalasset innerhalb des überwachten Dateiverzeichnisses, wie vorstehend beschrieben worden ist, geändert hat.
Sobald der Komponentenverwalter 212 (und/oder der Packungsverwalter) die modifizierte gepackte Datei für das Digitalasset erzeugt und speichert, synchronisiert, siehe 712, der Komponentenverwalter 212 die modifizierten Komponenten des Digitalassets mit dem Cloudsynchronisierungssystem 232. Wie vorstehend beschrieben worden ist, detektiert der Komponentenverwalter 212 bei einigen Ausführungsformen beim Synchronisieren mit dem Cloudsynchronisierungssystem 232 zusätzliche Änderungen an dem Digitalasset. Entsprechend empfängt das Digitalassetsynchronisierungssystem 210 die aktualisierten Komponenten und wiederholt den Prozess des Aktualisierens der gepackten Datei, wie hier beschrieben wird, was zudem ein Neuerzeugen der gepackten Datei für das Digitalasset beinhalten kann.
Zusätzlich stellt der Komponentenverwalter 212, wie gezeigt ist, die modifizierte gepackte Datei für das Digitalasset für die Anwendung 226 bereit, siehe 714. Die Anwendung 226 zeigt das modifizierte Digitalasset sodann dem Nutzer an, siehe 716. Bei einer oder mehreren Ausführungsformen kommuniziert der Komponentenverwalter 212, wie vorstehend beschrieben worden ist, mit der Anwendung 226, um einen Komponentenzugriff auf die neuerstellte gepackte Datei der aktualisierten Komponente, die an die bestehende gepackte Datei angehängt worden ist, zu erhalten, woraufhin der Komponentenverwalter 212 die alte Komponente aus der Komponentendatenbank löscht.
8 zeigt ein Sequenzdiagramm des Digitalassetsynchronisierungssystems 210 beim Aktualisieren einer gepackten Datei auf Grundlage eines aktualisierten Digitalassets, das von dem Cloudsynchronisierungssystem 232 empfangen wird. Das Digitalassetsynchronisierungssystem 210 detektiert beispielsweise, dass ein Digitalasset auf dem Cloudsynchronisierungssystem 232 eine aktuellere Version als die auf der Clientvorrichtung 202 gespeicherte Version ist.
Wie gezeigt ist, zeigt das Cloudsynchronisierungssystem 232 gegenüber dem Überwachungsagent 220 an, siehe 802, dass eine aktualisierte Komponente eines Digitalassets auf dem Cloudsynchronisierungssystem 232 verfügbar ist. In Reaktion hierauf schlägt der Überwachungsagent 220 die Komponentenkennung nach, siehe 804. Der Überwachungsagent 220 greift beispielsweise auf eine Nachschlagetabelle zu, um zu identifizieren, welchem Digitalasset die aktualisierte Komponente entspricht. Zusätzlich stellt der Überwachungsagent 220 die Komponentenkennung für den Komponentenverwalter 212 bereit, siehe 806.
Der Komponentenverwalter 212 verwendet die Komponentenkennung bei der dargestellten Ausführungsform zum Abrufen, siehe 808, der aktualisierten Komponente von dem Cloudsynchronisierungssystem 232. Der Komponentenverwalter 212 erhält mittels Pulling die aktualisierte Komponente beispielsweise aus dem Cloudsynchronisierungssystem 232, wie vorstehend beschrieben worden ist. Beim Herunterladen der aktualisierten Komponente speichert der Komponentenverwalter 212 die aktualisierte Komponente vorübergehend in der Komponentendatenbank.
Bei einigen Ausführungsformen treten ein oder mehrere Konflikte zwischen Komponenten des Digitalassets bei der modifizierten Komponente, die von dem Komponentenverwalter 212 abgerufen worden ist, und bei Komponenten, die unlängst auf der Clientvorrichtung 202 aktualisiert worden sind, auf. Entsprechend behebt der Komponentenverwalter 212, wie in 8 gezeigt ist, gegebenenfalls Konflikte mit dem Digitalasset, siehe 810. Insbesondere ist beim Abrufen und Aktualisieren der gepackten Datei gegebenenfalls eine weitere Änderung an demselben Digitalasset vorgenommen worden, was einen Konflikt zwischen den verschiedenen Versionen des Digitalassets bewirkt. Die detaillierte Erläuterung der Behebung von Konflikten bei denselben oder zwischen verschiedenen Komponenten eines Digitalassets ist vorstehend anhand 2 angegeben. Zusätzlich kann der Komponentenverwalter 212 die gepackte Datei für das Digitalasset auf der Clientvorrichtung 202 während des Behebungsprozesses, wie vorstehend beschrieben worden ist, aktualisieren und/oder modifizieren.
Bei Ausführungsformen, bei denen der Komponentenverwalter 212 Konflikte zwischen Komponenten des Digitalassets behebt, synchronisiert, siehe 812, der Komponentenverwalter 212 die Komponenten, an denen eine Behebung erfolgt ist, erneut mit dem Cloudsynchronisierungssystem 232. Wie vorstehend beschrieben worden ist, kann der Komponentenverwalter 212 beim Synchronisieren verifizieren, dass die Version auf dem Cloudsynchronisierungssystem 232 zur Version auf der Clientvorrichtung 202 passt (beispielsweise passen der Cloudzweig und der lokale Zweig). Beinhaltet das Cloudsynchronisierungssystem 232 zusätzliche Modifikationen, so kann das Digitalassetsynchronisierungssystem 210 die zusätzlichen Modifikationen, wie vorstehend beschrieben worden ist, iterativ abrufen und einbeziehen.
Nachdem Komponentenkonflikte behoben und die Komponenten mit dem Cloudsynchronisierungssystem 232 synchronisiert worden sind, erstellt der Komponentenverwalter (und/oder der Packungsverwalter) eine aktualisierte gepackte Datei für das Digitalasset, siehe 814. Wie vorstehend beschrieben worden ist, hängen der Komponentenverwalter 212 und/oder der Packungsverwalter (nicht gezeigt) die modifizierte Komponente an die bestehende gepackte Datei an oder erzeugen eine neue gepackte Datei. Beim Aktualisieren der gepackten Datei für das Digitalasset speichert, siehe 816, der Komponentenverwalter 212 die gepackte Datei für das Digitalasset in dem überwachten Dateiverzeichnis. Der Komponentenverwalter 212 kann die modifizierte Komponente zudem aus der Komponentendatenbank entfernen.
9 zeigt ein Sequenzdiagramm des Digitalassetsynchronisierungssystems 210 beim Öffnen einer gepackten Datei auf der Clientvorrichtung 202. Wie vorstehend erwähnt worden ist, ist eine Anwendung (beispielsweise die Anwendung 226) dafür ausgelegt, ein Digitalasset, das aus Komponenten besteht, korrekt anzuzeigen, damit das Digitalasset gegenüber einem Nutzer als eine einzige monolithische Datei angezeigt wird. Insbesondere kommuniziert die Anwendung mit dem Komponentenverwalter 212 des Digitalassetsynchronisierungssystems 210 zu dem Zweck, dass ein Zugriff auf jede Komponente in der Komponentendatenbank erfolgt, sowie zu dem Zweck, dass angegeben wird, wann eine Nutzereingabe Modifikationen an einer Komponente des Digitalassets bewirkt.
Wie in 9 gezeigt ist, empfängt, siehe 902, die Anwendung 226 eine Anforderung dahingehend, ein Digitalasset zu öffnen. Ein Nutzer fordert beispielsweise an, dass die Anwendung 226 eine gepackte Datei für ein Digitalasset innerhalb der Anwendung 226 öffnet. Als Teil des Empfangens der Anforderung, das Digitalasset zu öffnen, empfängt die Anwendung 226 die Abbildung (beispielsweise den Dateiortpfad) des Digitalassets. Bei einigen Ausführungsformen beinhaltet die Anwendung einen Komponentensubverwalter, der die Interaktion mit Komponenten eines Digitalassets wie auch die Kommunikation mit anderen Elementen des Digitalassetsynchronisierungssystems 210, wie vorstehend ausgeführt, erleichtert.
Beim Empfangen der Anforderung bestimmt, siehe 904, die Anwendung 226, dass das Digitalasset aus Komponenten besteht. Wie vorstehend beschrieben worden ist, ist die Anwendung 226 dafür ausgelegt, mit Komponenten eines Digitalassets zu interagieren. Als solches kann die Anwendung 226 bestimmen, ob ein Synchronisierungssystem 210 eine gepackte Datei ist, die Komponenten eines Digitalassets beinhaltet, oder ob das Digitalasset eine herkömmliche Datei ist. Bei einigen Ausführungsformen interagiert die Anwendung 226 lediglich mit Digitalassets, die aus Komponenten bestehen, die entweder in einer gepackten Datei oder in der Datenbank gespeichert sind.
Nach dem Verifizieren, dass das Digitalasset aus Komponenten besteht, führt die Anwendung 226 einen Handshake mit dem Überwachungsagent 220 durch, siehe 906, um eine Kennung (beispielsweise eine Aufzeichnungskennung) für das Digitalasset zu empfangen. Insbesondere stellt die Anwendung 226 den Pfad des Digitalassets für den Überwachungsagent 220 bereit, der die Aufzeichnungskennung für das Digitalasset nachschlägt und sie wiederum für die Anwendung 226 bereitstellt. Bei verschiedenen Ausführungsformen kann eine Komponenteninteraktionsschnittstelle (beispielsweise ein Komponentensubverwalter) innerhalb der Anwendung 226 eine IPC mit dem Überwachungsagent 220 einsetzen, um den Handshake zu initiieren.
Zusätzlich wird mittels Durchführen des Handshakes mit dem Überwachungsagent 220 der Überwachungsagent 220 davon benachrichtigt, dass die Anwendung 226 auf das Digitalasset zugreift. Als solches kann der Überwachungsagent 220 den Komponentenverwalter 212 dahingehend informieren, mit der Anwendung 226 zu kommunizieren, um Änderungen an Komponenten des Digitalassets zu implementieren. Der Überwachungsagent 220 kann zudem Änderungen an dem Cloudsynchronisierungssystem 232 detektieren und darüber berichten, wenn diese an dem Digitalasset auftreten.
Bei einigen Ausführungsformen lokalisiert der Überwachungsagent 220 anfänglich die Aufzeichnungskennung für das Digitalasset nicht. Das Digitalasset ist beispielsweise neu und noch nicht bei dem Überwachungsagent 220 registriert. Anstelle der Ausgabe einer Nullkennung an die Anwendung 226, die bewirken würde, dass ein Fehler beim Öffnen in der Anwendung 226 auftritt, ruft der Überwachungsagent 220 die Funktion zum Erstellen einer neuen gepackten Datei für ein Digitalasset auf, wie anhand 3 und 4 beschrieben worden ist. Ist die gepackte Datei vorhanden, so erkennt der Überwachungsagent 220 daher das Digitalasset und arbeitet mit dem Komponentenverwalter 212 zur Registrierung des Digitalassets. Der Überwachungsagent 220 gibt sodann die neuzugeteilte Digitalassetkennung an die Anwendung 226 aus. Ist dem nicht so, so gibt der Überwachungsagent 220, wie vorstehend beschrieben worden ist, eine Nullkennung aus.
Unter Verwendung der Kennung für das Digitalasset greift die Anwendung 226 auf die Komponenten in Verbindung mit dem Komponentenverwalter 212 zu, siehe 908. Während die Anwendung 226 die Komponenten aus der gepackten Datei für das Digitalasset lädt, kommuniziert die Anwendung 226 beispielsweise zudem mit dem Komponentenverwalter 212, um anzugeben, wann ein Nutzer Änderungen an einer oder mehreren Komponenten des Digitalassets vornimmt. Auf diese Weise kann der Komponentenverwalter 212 (und/oder der Packungsverwalter), wie vorstehend beschrieben worden ist, die gepackte Datei aktualisieren, um die empfangenen Modifikationen wiederzugeben.
Darüber hinaus zeigt die Anwendung 226 das Digitalasset gegenüber dem Nutzer als eine monolithische Datei an, siehe 910. Wie vorstehend erwähnt worden ist, lädt die Anwendung 226 die Komponenten aus der gepackten Datei für das Digitalasset und stellt das Digitalasset für den Nutzer als eine einzige Datei bereit. Bei einigen Ausführungsformen ermöglicht die Anwendung 226, dass der Nutzer einzelne Komponenten zeigt/verbirgt oder verborgene Komponenten (beispielsweise Komponenten, die Metadaten für das Digitalasset beinhalten), betrachtet.
In 10 bis 12 sind zusätzliche Beispiele für das Digitalassetsynchronisierungssystem 210 beim Löschen von gepackten Dateien angegeben. Insbesondere zeigt 10 einen Nutzer beim Löschen eines Digitalassets (beispielsweise einer gepackten Datei für das Digitalasset). Insbesondere zeigt 10 das Digitalassetsynchronisierungssystem 210 beim Löschen eines Digitalassets von der Clientvorrichtung auf Grundlage einer Nutzereingabe, die das Digitalassetsynchronisierungssystem 210 auffordert, das Digitalasset aus dem überwachten Dateiverzeichnis direkt auf der Clientvorrichtung 202 zu entfernen.
Wie gezeigt ist, detektiert, siehe 1002, der Überwachungsagent 220 eine entfernte gepackte Datei für ein Digitalasset. Ein Nutzer löscht beispielsweise das Digitalasset, indem er das Digitalasset in ein Abfallverzeichnis verschiebt. Bei einem anderen Beispiel verschiebt der Nutzer das Digitalasset aus dem überwachten Dateiverzeichnis heraus in ein nichtüberwachtes Verzeichnis hinein. Bei einigen Ausführungsformen wird der Befehl zum Entfernen einer gepackten Datei gegeben, wenn die gepackte Datei überschrieben wird. Das Überschreiben des Digitalassets erstellt beispielsweise zunächst ein neues Digitalasset und löscht sodann das ältere Digitalasset, wie vorstehend anhand 3 und 4 beschrieben worden ist.
Beim Detektieren der entfernten gepackten Datei für das Digitalasset berichtet, siehe 1004, der Überwachungsagent 220 dem Komponentenverwalter 212 von der entfernten gepackten Datei. Der Überwachungsagent 220 schlägt beispielsweise die Kennung für das Digitalasset nach und leitet die Digitalassetkennung zusammen mit Entfernungsanweisungen an den Komponentenverwalter 212 weiter.
Der Komponentenverwalter 212 markiert, siehe 1006, die Komponenten in der gepackten Datei für das Digitalasset, damit diese aus dem Digitalassetsynchronisierungssystem 210 auf der Clientvorrichtung 202 entfernt werden. Auf diese Weise verhindert der Komponentenverwalter 212 das Vornehmen zusätzlicher Hinzufügungen oder Modifikationen an dem Digitalasset. Erfolgt beispielsweise das Entfernen eines Digitalassets während des nächsten Synchronisierungszyklus, so erfolgt das Entfernen des Digitalassets gegebenenfalls nicht unmittelbar. Aufgrund der Verzögerung beim Entfernen einer Datei erstellt der Komponentenverwalter 212 bei einigen Ausführungsformen, wenn er Hinzufügungen oder andere Modifikationen an dem Digitalasset detektiert, eine neue gepackte Datei für das Digitalasset, wie vorstehend anhand 3 und 4 beschrieben worden ist. Hat eine Anwendung das Digitalasset aktuell geöffnet, so kann der Komponentenverwalter 212 beispielsweise damit fortfahren, Kopien der Komponenten des Digitalassets zu speichern, bis Konfliktbehebungsschritte beendet sind, wie vorstehend beschrieben worden ist.
Darüber hinaus bestätigt der Komponentenverwalter 212 gegenüber dem Überwachungsagent 220, dass das Digitalasset eine gepackte Datei und keine herkömmliche Datei oder ein Digitalasset ist, das in der Komponentendatenbank gespeichert ist. Ist das Digitalasset als gepackte Datei gespeichert, so gibt der Komponentenverwalter 212 die Digitalassetkennung für das Digitalasset zusammen mit einem Hinweis auf das Koordinieren/Initiieren des Entfernens des Digitalassets von dem Digitalassetsynchronisierungssystem 210 aus. Wie gezeigt ist, zeigt der Komponentenverwalter 212 beim Markieren des Digitalassets zum Entfernen den Entfernungsstatus gegenüber dem Überwachungsagent 220 an, siehe 1008.
Zusätzlich stellt der Komponentenverwalter 212 für den Überwachungsagent 220 einen Hinweis auf das Löschen/Archivieren von Komponenten der gepackten Datei für das Digitalasset bereit, siehe 1010. Insbesondere zeigt der Komponentenverwalter 212 gegenüber dem Cloudsynchronisierungssystem 232 an, dass das Digitalasset von der Clientvorrichtung 202 entfernt worden ist. Als solches speichert/archiviert das Cloudsynchronisierungssystem 232 die Komponenten der gepackten Datei für das Digitalasset für wenigstens eine gewisse Zeitspanne (beispielsweise dreißig Tage, sechs Monate, ein Jahr), bevor die Löschung erfolgt. Auf diese Weise kann der Nutzer bei Bedarf auf das Digitalasset zugreifen und dieses wiederherstellen. Alternativ löscht das Cloudsynchronisierungssystem 232 die Komponenten beim Empfangen des Hinweises von dem Komponentenverwalter 212.
Das Cloudsynchronisierungssystem 232 bestätigt die Löschung/Archivierung der Komponenten des Digitalassets gegenüber dem Komponentenverwalter 212. Beim Empfangen, siehe 1012, einer Bestätigung von dem Cloudsynchronisierungssystem 232 zeigt der Komponentenverwalter 212 gegenüber dem Überwachungsagent 220 an, siehe 1014, dass das Cloudsynchronisierungssystem 232 Komponenten des Digitalassets erfolgreich gelöscht/archiviert hat. Der Überwachungsagent 220 löscht, siehe 1016, sodann die gepackte Datei für das Digitalasset aus dem überwachten Dateiverzeichnis. Zusätzlich kann der Komponentenverwalter 212 beliebige Komponenten und/oder Metadaten, die mit dem Digitalasset verknüpft sind, aus der Komponentendatenbank entfernen.
11 zeigt einen Nutzer beim Löschen eines Digitalassets, das als gepackte Datei gespeichert ist, mittels einer Anwendung. Wie gezeigt ist, zeigt die Anwendung 226 die Komponenten einer gepackten Datei (das heißt ein Digitalasset) einem Nutzer als monolithische Datei an, siehe 1102. Die Anwendung 226 öffnet das Digitalasset beispielsweise und zeigt dieses an, wie vorstehend anhand 9 beschrieben worden ist.
Betrachtet der Nutzer das Digitalasset innerhalb der Anwendung 226, so empfängt, siehe 1104, die Anwendung 226 von einem Nutzer eine Anforderung dahingehend, die gepackte Datei zu löschen. Der Nutzer wählt beispielsweise eine Option innerhalb der Anwendung 226 aus, um das Digitalasset oder alle Komponenten der gepackten Datei zu löschen. Bei einem weiteren Beispiel ersetzt oder überschreibt der Nutzer die gepackte Datei durch einen anderen Digitalasset, wie vorstehend beschrieben worden ist. In Reaktion hierauf zeigt die Anwendung 226 die Löschung der gepackten Datei gegenüber dem Komponentenverwalter 212 an, siehe 1106.
Beim Empfangen des Löschhinweises markiert, siehe 1108, der Komponentenverwalter 212 die Komponenten zur Löschung. Der Komponentenverwalter 212 verknüpft beispielsweise Metadaten mit den Komponenten in der Komponentendatenbank, die die Komponenten zur Entfernung von dem Digitalassetsynchronisierungssystem 210 markiert. Der Komponentenverwalter 212 koordiniert des Weiteren gegebenenfalls die gepackte Datei zur Entfernung im nächsten Synchronisierungszyklus innerhalb des Digitalassetsynchronisierungssystems 210.
Wie in 11 gezeigt ist, führt der Komponentenverwalter 212 zudem eine Löschung/Archivierung der Komponenten der gepackten Datei für das Digitalasset durch, siehe 1110. Wie vorstehend anhand 10 beschrieben worden ist, zeigt der Komponentenverwalter 212 gegenüber dem Cloudsynchronisierungssystem 232 an, dass das Digitalasset von der Clientvorrichtung 202 entfernt wird. In Reaktion hierauf speichert, archiviert, entfernt und/oder löscht das Cloudsynchronisierungssystem 232 die Komponenten der gepackten Datei für das Digitalasset. Darüber hinaus bestätigt das Cloudsynchronisierungssystem 232, wenn bzw. wann die Komponenten archiviert worden sind. Wie gezeigt ist, löscht, siehe 1112, der Überwachungsagent 220 die gepackte Datei aus dem überwachten Dateiverzeichnis, wie vorstehend anhand 10 beschrieben worden ist.
12 zeigt das Digitalassetsynchronisierungssystem 210 beim Empfangen eines Hinweises, dass eine gepackte Datei (das heißt ein Digitalasset) von dem Cloudsynchronisierungssystem 232 gelöscht worden ist. Ein Nutzer löscht beispielsweise die gepackte Datei auf einer anderen Clientvorrichtung, die sich sodann mit dem Cloudsynchronisierungssystem 232 synchronisiert, und bewirkt, dass das Cloudsynchronisierungssystem 232 die gepackte Datei archiviert/löscht. Das Cloudsynchronisierungssystem 232 benachrichtigt wiederum die Clientvorrichtung 202 über die gelöschte gepackte Datei, damit das Digitalassetsynchronisierungssystem 210 auf der Clientvorrichtung 202 angewiesen wird, die gepackte Datei für das Digitalasset zu entfernen.
Insbesondere zeigt 12 das Cloudsynchronisierungssystem 232 beim Löschen, siehe 1202, der gepackten Datei auf der Servervorrichtung 230. Wie vorstehend beschrieben worden ist, löscht oder archiviert das Cloudsynchronisierungssystem 232 bei einer oder mehreren Ausführungsformen die Komponenten der gepackten Datei. Beim Archivieren der Komponenten, die mit dem Digitalasset verknüpft sind, speichert das Cloudsynchronisierungssystem 232 die Komponenten (wenigstens für eine gewisse Zeit) innerhalb einer Remote-Komponentendatenbank. Zusätzlich bewirkt das Cloudsynchronisierungssystem 232, dass die mit dem Cloudsynchronisierungssystem 232 synchronisierten Clientvorrichtungen die gepackte Datei für das Digitalasset, darunter alle Komponenten, die in der gepackten Datei gespeichert sind, löschen/entfernen.
Beim Löschen oder Entfernen der gepackten Datei stellt das Cloudsynchronisierungssystem 232 einen Hinweis für den Überwachungsagent 220 dahingehend bereit, siehe 1204, die gepackte Datei auf der Clientvorrichtung 202 zu löschen. Beim Empfangen des Hinweises schlägt der Überwachungsagent 220 die Digitalassetkennung für die gepackte Datei, wie vorstehend beschrieben worden ist, nach, siehe 1206. Wie ebenfalls beschrieben worden ist, stellt der Überwachungsagent 220 die Digitalassetkennung für den Komponentenverwalter 212 zusammen mit Anweisungen dahingehend, die gepackte Datei zu entfernen, bereit, siehe 1208. Des Weiteren markiert, siehe 1210, der Komponentenverwalter 212 die Komponenten des Digitalassets zur Löschung, wie vorstehend beschrieben worden ist.
Bei einer oder mehreren Ausführungsformen wird die gepackte Datei aktiv von einer Anwendung oder auf andere Weise auf der Clientvorrichtung 202 verwendet. Bei diesen Ausführungsformen wartet der Komponentenverwalter 212 zunächst auf die Behebung, siehe 1212, von Konflikten mit dem Digitalasset, was das Aktualisieren der Komponentendatenbank und/oder der gepackten Datei für das Digitalasset impliziert. Wie vorstehend beschrieben worden ist, können Konflikte beinhalten, dass der Komponentenverwalter 212 eine neue gepackte Datei für das Digitalasset erstellt, die Modifikationen beinhaltet, wobei die Modifikationen detektiert werden, nachdem der Komponentenverwalter 212 die Anweisungen zum Löschen der gepackten Datei empfangen hat. Bei diesen Ausführungsformen synchronisiert, siehe 1214, der Komponentenverwalter 212 sodann die Komponenten, an denen eine Behebung erfolgt ist, mit dem Cloudsynchronisierungssystem 232, wie vorstehend beschrieben worden ist.
Empfängt der Komponentenverwalter 212 Anweisungen zum Markieren der gepackten Datei zur Löschung, so löscht, siehe 1216, der Überwachungsagent 220 die gepackte Datei für das Digitalasset. Wie vorstehend beschrieben worden ist, zeigt der Komponentenverwalter 212 gegenüber dem Überwachungsagent 220 beispielsweise an, dass das Cloudsynchronisierungssystem 232 den Digitalasset erfolgreich gelöscht/archiviert hat. Hierauf löscht der Überwachungsagent 220 die gepackte Datei für das Digitalasset aus dem überwachten Dateiverzeichnis. Darüber hinaus kann der Komponentenverwalter 212 beliebige Komponenten und/oder Metadaten, die mit dem Digitalasset verknüpft sind, aus der Komponentendatenbank entfernen.
13 zeigt ein Zustandsdiagramm 1300 des Digitalassetsynchronisierungssystems 210 beim auf einer Clientvorrichtung erfolgenden Durchführen eines Schrittes zum Vorhalten einer Speicherung des Teilsatzes von Komponenten zwischen einer Komponentendatenbank und einer gepackten Datei. Die Komponentendatenbank umfasst Komponenten, die als unabhängige Dateien über die Clientvorrichtung hinweg gespeichert sind. Erläuterungshalber wird auf das Digitalassetsynchronisierungssystem 210, das Cloudsynchronisierungssystem 232 und die Clientvorrichtung 202, die vorstehend beschrieben worden sind, verwiesen. Die Beschreibung von 13 verweist des Weiteren auf die vorstehende Beschreibung der Figuren im Zusammenhang mit Schritten, Handlungen, Vorgängen und/oder Funktionen, die von dem Digitalassetsynchronisierungssystem 210 durchgeführt werden.
Wie gezeigt ist, empfängt, siehe 1302, das Digitalassetsynchronisierungssystem 210 ein Manifest und eine Komponente einer gepackten Datei von dem Cloudsynchronisierungssystem 232 (das empfangene Manifest zeigt beispielsweise die Komponente an). Das Digitalassetsynchronisierungssystem 210 nimmt beispielsweise ein Anfordern, ein mittels Pulling erfolgendes Übertragen und/oder ein Herunterladen einer oder mehrerer Komponenten eines Digitalassets (wie in dem empfangenen Manifest einer gepackten Datei angegeben) von dem Cloudsynchronisierungssystem 232 vor, wie vorstehend beschrieben worden ist. Alternativ nimmt das Cloudsynchronisierungssystem 232 ein Senden oder ein mittels Pushing erfolgendes Übertragen der einen oder der mehreren Komponenten an das Digitalassetsynchronisierungssystem 210 auf einer Clientvorrichtung 202 vor.
Die Beschreibung von 13 beschreibt im Übrigen das Digitalassetsynchronisierungssystem 210 beim Empfangen einer einzigen Komponente von dem Cloudsynchronisierungssystem 232 in Verbindung mit einem empfangenen Manifest. Es sollte einsichtig sein, dass das Cloudsynchronisierungssystem 232 zusätzliche Komponenten bereitstellen kann. Die Absicht besteht jedoch darin, dass das Cloudsynchronisierungssystem 232 weniger als alle Komponenten eines Digitalassets bereitstellt (beispielsweise nur modifizierte Komponenten, die sich im Vergleich zu einem vorherigen Manifest geändert haben). Mit anderen Worten, das Digitalassetsynchronisierungssystem 210 erstellt, wie nachstehend noch beschrieben wird, eine neue gepackte Datei für ein Digitalasset, wenn weniger als alle Komponenten (das heißt eine Teilsatz) für ein bestehendes Digitalasset empfangen werden, das als gepackte Datei von Komponenten, die das Digitalasset bilden, gespeichert ist.
Als Nächstes identifiziert, siehe 1304, das Digitalassetsynchronisierungssystem 210 die Komponentenkennung der empfangenen Komponente. Das Digitalassetsynchronisierungssystem 210 schlägt beispielsweise eine Kennung für die empfangene Komponente innerhalb des Manifests nach. Bei einigen Ausführungsformen teilt das Digitalassetsynchronisierungssystem 210 eine neue lokale Komponentenkennung für die empfangene Komponente zu. Zusätzlich schlägt das Digitalassetsynchronisierungssystem 210 eine Digitalassetkennung (beispielsweise eine Aufzeichnungskennung) für das Digitalasset, zu dem das empfangene Manifest und die Komponente gehören, nach.
Das Digitalassetsynchronisierungssystem 210 bestimmt, ob das empfangene Manifest eine andere Version eines bestimmten Digitalassets angibt. Das Digitalassetsynchronisierungssystem 210 bestimmt beispielsweise, dass das empfangene Manifest des Digitalassets eine neue Komponente oder eine modifizierte Version einer Komponente (beispielsweise die empfangene Komponente) im Vergleich zu denjenigen beinhaltet, die in dem auf der Clientvorrichtung 202 befindlichen, bestehenden Manifest beinhaltet sind. Detektiert das Digitalassetsynchronisierungssystem 210 verschiedene Manifeste (das heißt Versionen) für das gleiche Digitalasset zwischen dem empfangenen Manifest und dem bestehenden Manifest auf der Clientvorrichtung 202, wie in 13 gezeigt ist, so bestimmt, siehe 1306, das Digitalassetsynchronisierungssystem 210, ob das empfangene Manifest einen Versionskonflikt für das Digitalasset erzeugt.
Erzeugt das empfangene Manifest keinen Versionskonflikt (stellt das empfangene Manifest beispielsweise eine Aktualisierung an dem bestehenden Manifest, das auf der Clientvorrichtung 202 befindlich ist, bereit), so erzeugt, siehe 1308, das Digitalassetsynchronisierungssystem 210 eine neue gepackte Datei mit der empfangenen Komponente auf Grundlage des empfangenen Manifests. Das Digitalassetsynchronisierungssystem 210 erzeugt beispielsweise eine neue gepackte Datei oder hängt die empfangene Komponente an eine bestehende gepackte Datei für das Digitalasset an. Die Beschreibung im Zusammenhang mit dem Digitalassetsynchronisierungssystem 210 beim Erzeugen einer neuen gepackten Datei ist vorstehend anhand 2 bis 5 detaillierter erfolgt. Zusätzlich und/oder alternativ setzt das Digitalassetsynchronisierungssystem 210 Aktionen ein, die anhand 6 bis 8 beschrieben worden sind und bei denen das Digitalassetsynchronisierungssystem 210 eine gepackte Datei für ein Digitalasset auf Grundlage dessen, dass eine Komponente des Digitalassets modifiziert wird, aktualisiert.
Beim Erzeugen einer neuen gepackten Datei für ein Digitalasset entfernt, siehe 1310, das Digitalassetsynchronisierungssystem 210 die empfangene Komponente aus einer lokalen Datenbank. Insbesondere entfernt das Digitalassetsynchronisierungssystem 210 die empfangene Komponente aus der Komponentendatenbank. Wie vorstehend wenigstens anhand 2 und 7 beschrieben worden ist, speichert das Digitalassetsynchronisierungssystem 210 die empfangene Komponente vorübergehend innerhalb einer Komponentendatenbank beim Empfangen der Komponente, bis die empfangene Komponente erfolgreich innerhalb einer aktualisierten oder neuen gepackten Datei für das Digitalasset gepackt ist.
Bestimmt das Digitalassetsynchronisierungssystem 210, dass das empfangene Manifest mit dem bestehenden Manifest auf der Clientvorrichtung für das Digitalasset in Konflikt steht (ist beispielsweise eine entsprechende Komponente auf der Clientvorrichtung 202 vor dem Empfangen der empfangenen Komponente modifiziert, jedoch nicht mit dem Cloudsynchronisierungssystem 232 synchronisiert worden), so behebt, siehe 1312, das Digitalassetsynchronisierungssystem 210 den Konflikt zwischen den mehreren Manifestversionen (beispielsweise dem empfangenen Manifest und dem bestehenden Manifest auf der Clientvorrichtung 202, das noch nicht mit dem Cloudsynchronisierungssystem 232 synchronisiert worden ist). Das Digitalassetsynchronisierungssystem 210 setzt die vorstehend anhand 2 beschriebenen Aktionen ein, um den Konflikt zwischen den verschiedenen Manifestversionen des Digitalassets zu beheben. Als Teil des Behebens des Komponentenkonfliktes kann, wie gezeigt ist, das Digitalassetsynchronisierungssystem 210 das empfangene Manifest auswählen, das die Verwendung der empfangenen Komponente angibt, und eine neue gepackte Datei mit der empfangenen Komponente, wie vorstehend beschrieben worden ist, erzeugen, siehe 1308.
Alternativ wählt das Digitalassetsynchronisierungssystem 210 das bestehende Manifest aus und synchronisiert, siehe 1314, das bestehende Manifest und die entsprechende Komponente (beispielsweise die Komponente, die auf der Clientvorrichtung 202 aktualisiert ist) mit dem Cloudsynchronisierungssystem 232, bei dem eine Kopie des bestehenden Manifestes und/oder der Komponente fehlt. Bei anderen Ausführungsformen führt das Digitalassetsynchronisierungssystem 210 eine oder mehrere entsprechende Komponenten für die beiden verschiedenen Manifestversionen zusammen, um ein neues Manifest der gepackten Datei aufzunehmen. Bei diesen Ausführungsformen synchronisiert das Digitalassetsynchronisierungssystem 210 weiterhin die bestehende Komponente mit dem Cloudsynchronisierungssystem 232, da die bestehende Komponente noch nicht in dem Cloudsynchronisierungssystem 232 gespeichert ist. Des Weiteren synchronisiert das Digitalassetsynchronisierungssystem 210 eine aktualisierte Abbildung, die angibt, dass sowohl die empfangene Komponente wie auch die bestehende Komponente zu der aktualisierten gepackten Datei für das Digitalasset hinzugefügt worden sind.
1 bis 13, der entsprechende Text und die Beispiele stellen eine Anzahl von verschiedenen Systemen und Vorrichtungen des Digitalassetsynchronisierungssystems entsprechend einer oder mehreren Ausführungsformen bereit. Zusätzlich zur vorstehenden Beschreibung können eine oder mehrere Ausführungsformen auch anhand von Flussdiagrammen beschrieben werden, die Vorgänge bei einem Verfahren zum Erzielen eines bestimmten Ergebnisses umfassen. 14 und 15 zeigen beispielsweise Flussdiagramme für exemplarische Verfahren entsprechend einer oder mehreren der hier beschriebenen Ausführungsformen.
14 zeigt ein exemplarisches Flussdiagramm eines Verfahrens 1400 zum Erzeugen einer gepackten Datei aus Komponenten eines Digitalassets, die als unabhängige Dateien gespeichert sind. Bei einer oder mehreren Ausführungsformen ist das Verfahren 1400 auf einer oder mehreren Rechenvorrichtungen implementiert, so beispielsweise auf einer Clientvorrichtung und/oder einer Servervorrichtung. Des Weiteren ist das Verfahren 1400 bei einigen Ausführungsformen in einer digitalen Umgebung zum Durchführen einer Digitalassetverwaltung zwischen einer Rechenvorrichtung und einem Cloudspeichermedium implementiert.
Das Verfahren 1400 beinhaltet einen Vorgang 1410 des Vorhaltens einer Digitalassetabbildung, die angibt, wo Komponenten 216, die ein Digitalasset bilden, gespeichert sind. Der Vorgang 1410 beinhaltet beispielsweise ein auf einer Clientvorrichtung 202 erfolgendes Vorhalten einer Datenbank 214 mit einer Digitalassetabbildung, die angibt, wo Komponenten 216, die ein Digitalasset bilden, innerhalb der Datenbank 214 gespeichert sind und wo die Komponenten 216 als unabhängige Dateien, die über die Datenbank 214 (und/oder die Clientvorrichtung 202) hinweg verteilt sind, gespeichert sind. Bei einigen Ausführungsformen beinhaltet der Vorgang 1410 zudem ein Erzeugen eines Digitalassetmanifests, das die Komponenten mit dem Digitalasset verknüpft. Zusätzlich kann die Datenbank ein oder mehrere vorherige Digitalassetmanifeste des Digitalassets beinhalten, wobei jedes vorherige Digitalassetmanifest einer vorherigen Version des Digitalassets entspricht und wobei eine oder mehrere Komponenten, die vorherigen Versionen des Digitalassets entsprechen, auf einer Cloudspeichervorrichtung 230 vorgehalten werden.
Das Verfahren 1400 beinhaltet zudem einen Vorgang 1420 des Erzeugens einer gepackten Datei 100 des Digitalassets 102. Insbesondere kann der Vorgang 1420 ein auf der Clientvorrichtung 202 erfolgendes Erzeugen einer gepackten Datei 100 des Digitalassets 102 mit einer Kopie einer jeden der Komponenten 104 innerhalb der gepackten Datei 100 beinhalten. Beinhalten kann der Vorgang 1420 bei einer oder mehreren Ausführungsformen zudem das Synchronisieren der Komponenten 104 des Digitalassets 102 und des Digitalassetmanifests auf einer Cloudspeichervorrichtung 203 vor dem Erzeugen der gepackten Datei 100 des Digitalassets 102. Bei einigen Ausführungsformen beinhaltet das Erzeugen der gepackten Datei des Digitalassets ein Komprimieren einer jeden der Komponenten des Digitalassets in die gepackte Datei hinein.
Wie in 14 gezeigt ist, beinhaltet der Vorgang 1400 des Weiteren einen Vorgang 1430 des Erzeugens der aktualisierten Digitalassetabbildung. Insbesondere kann der Vorgang 1430 ein Erzeugen einer aktualisierten Digitalassetabbildung implizieren, um auf die Komponenten 104 des Digitalassets 102 innerhalb der gepackten Datei 100 zu verweisen. Bei einigen Ausführungsformen beinhaltet der Vorgang 1430 das Verknüpfen der aktualisierten Abbildung des Digitalassets innerhalb der erzeugten gepackten Datei. Zusätzlich und/oder alternativ impliziert der Vorgang 1430 das Aufnehmen anderer/zusätzlicher Metadaten in die erzeugte gepackte Datei.
Das Verfahren 1400 beinhaltet zudem eine Anzahl von zusätzlichen Schritten. Bei einigen Ausführungsformen beinhaltet das Verfahren 1400 zudem einen Vorgang des Entfernens der Komponenten 216, die als unabhängige Dateien, die über die Datenbank 214 hinweg verteilt sind, gespeichert werden. Implizieren kann dieser Vorgang insbesondere ein nach dem Aktualisieren der Digitalassetabbildung erfolgendes Entfernen der Komponenten 216, die als unabhängige Dateien, die über die Datenbank 214 (und/oder die Clientvorrichtung 202) hinweg verteilt sind, gespeichert sind. Bei einigen Ausführungsformen beinhaltet dieser Vorgang ein Löschen von duplizierten Komponenten innerhalb einer Komponentendatenbank, die ebenfalls in der gepackten Datei beinhaltet sind.
Bei einer oder mehreren Ausführungsformen beinhaltet das Verfahren 1400 die Vorgänge des Detektierens einer Modifikation an einer Komponente des Digitalassets; des in der Datenbank und in Reaktion auf das Detektieren der Modifikation an der Komponente erfolgenden Speicherns einer aktualisierten Kopie der Komponente, die die detektierten Modifikationen an der Komponente beinhaltet; des Modifizierens der gepackten Datei des Digitalassets, um die aktualisierte Kopie der Komponente aufzunehmen; und des Entfernens der aktualisierten Kopie der Komponente aus der Datenbank beim Modifizieren der gepackten Datei. Beinhalten kann das Verfahren des Weiteren die Vorgänge des innerhalb des Digitalassetmanifests erfolgenden Ersetzens einer Kennung, die mit der Komponente verknüpft ist, durch das Digitalasset mit einer Kennung, die mit der aktualisierten Kopie der Komponente mit dem Digitalasset verknüpft ist; und des beim Modifizieren der gepackten Datei erfolgenden Aktualisierens der modifizierten Digitalassetabbildung, um wiederzugeben, dass die aktualisierte Kopie der Komponente als Teil der modifizierten gepackten Datei gespeichert ist.
Bei einigen Ausführungsformen beinhaltet der Vorgang 1400 den Vorgang des Detektierens der Modifikation an der Komponente des Digitalassets auf Grundlage des Empfangs der aktualisierten Kopie der Komponente von der Cloudspeichervorrichtung. Beinhaltet sind bei dem Verfahren 1400 zudem die Vorgänge des Synchronisierens der aktualisierten Kopie der Komponente mit der Cloudspeichervorrichtung vor dem Modifizieren der gepackten Datei des Digitalassets ohne Synchronisieren anderer nichtmodifizierter Komponenten des Digitalassets und des Entfernens der aktualisierten Kopie der Komponente aus der Datenbank nach dem Durchführen der Synchronisierung.
Bei verschiedenen Ausführungsformen impliziert der Vorgang des Modifizierens der gepackten Datei des Digitalassets, damit diese die aktualisierte Kopie der Komponente beinhaltet, des Weiteren das Erzeugen einer zusätzlichen gepackten Datei des Digitalassets, die die aktualisierte Kopie der Komponente anstelle der Komponente beinhaltet, und das Entfernen der gepackten Datei von der Clientvorrichtung. Bei alternativen Ausführungsformen impliziert der vorgenannte Vorgang des Weiteren das Anhängen einer komprimierten Kopie der aktualisierten Kopie der Komponente an die gepackte Datei, um die modifizierte gepackte Datei zu erstellen, und das Entfernen der gepackten Datei von der Clientvorrichtung beim Erstellen der modifizierten gepackten Datei einschließlich des Entfernens der Komponente von der Clientvorrichtung.
Das Verfahren 1400 beinhaltet bei einer oder mehreren Ausführungsformen den Vorgang des Bestimmens zum Erzeugen einer zusätzlichen gepackten Datei auf Grundlage einer Überschreitung einer Redundanzschwelle. Die Redundanzschwelle wird beispielsweise überschritten, wenn die gepackte Datei eine Schwellenmenge (beispielsweise eine Anzahl) von veralteten Komponenten als Ergebnis des Anhängens einer oder mehrerer modifizierter Komponenten an die gepackte Datei beinahltet. Bei einigen Ausführungsformen ist die Schwellenmenge ein Datei-Größe-Verhältnis oder ein Anzahlverhältnis von veralteten Komponenten zu aktuellen Komponenten.
Bei verschiedenen Ausführungsformen beinhaltet das Verfahren 1400 den Vorgang des Überwachens von Digitalassets, die in einem überwachten Dateiverzeichnis der Clientvorrichtung befindlich sind. Bei diesen Vorgängen wird jedes der Digitalassets innerhalb des überwachten Dateiverzeichnisses in der Datenbank registriert. Des Weiteren wird jedes der Digitalassets innerhalb des überwachten Dateiverzeichnisses mit der Cloudspeichervorrichtung synchronisiert.
15 zeigt ein exemplarisches Flussdiagramm eines Verfahrens 1500 zum Erzeugen einer modifizierten gepackten Datei. Bei einer oder mehreren Ausführungsformen ist das Verfahren 1500 auf einer oder mehreren Rechenvorrichtungen, so beispielsweise auf einer Clientvorrichtung und/oder einer Servervorrichtung, implementiert. Das Verfahren 1500 ist beispielsweise auf einer Clientvorrichtung 202 implementiert, die eine Datenbank 214 aufweist, die ein Manifest 218 speichert, das Komponenten 104, die ein Digitalasset 102 bilden, identifiziert. Insbesondere ist jede der Komponenten 104 des Digitalassets 102 in einer gepackten Datei 100 gespeichert. Zusätzlich verfügt jede Komponente innerhalb des Digitalassets über eine vordefinierte Grenze, die modifizierbar ist, ohne andere Komponenten des Digitalassets zu beeinflussen.
Wie gezeigt ist, beinhaltet das Verfahren 1500 einen Vorgang 1510 des Detektierens einer Modifikation an einer Komponente. Insbesondere kann der Vorgang 1510 das Detektieren einer Modifikation an einer Komponente des Digitalassets 102 beinhalten. Bei einer oder mehreren Ausführungsformen beinhaltet der Vorgang 1510 das Detektieren der Modifikation an der Komponente des Digitalassets bei einer Anwendung 226, die auf der Clientvorrichtung 202 befindlich ist, wobei die Anwendung die gepackte Datei des Digitalassets als monolithische Datei anzeigt. Bei verschiedenen Ausführungsformen beinhaltet der Vorgang 1510 ein von der Anwendung her erfolgendes Empfangen einer Inter-Prozess-Kommunikation (IPC) zur Angabe dessen, dass eine oder mehrere Komponenten des Digitalassets modifiziert worden sind.
Das Verfahren 1500 beinhaltet zudem einen Vorgang 1520 des Erstellens einer aktualisierten Kopie der Komponente. Der Vorgang 1520 kann insbesondere ein in der Datenbank 214 und in Reaktion auf das Detektieren der Modifikation an der Komponente erfolgendes Erstellen einer aktualisierten Kopie der Komponente, die die detektierten Modifikationen an der Komponente beinhaltet, implizieren. Bei einigen Ausführungsformen beinhaltet der Vorgang 1520 das Senden der aktualisierten Kopie der Komponente an eine Cloudspeichervorrichtung beim Erstellen der aktualisierten Kopie der Komponente.
Zusätzlich beinhaltet das Verfahren 1500 einen Vorgang 1530 des Ersetzens der Komponente durch die aktualisierte Kopie der Komponente. Insbesondere kann der Vorgang 1530 ein in dem Manifest erfolgendes Ersetzen einer Kennung, die die Komponente mit dem Digitalasset verknüpft, durch eine Kennung, die die aktualisierte Kopie der Komponente mit dem Digitalasset verknüpft, implizieren. Bei einigen Ausführungsformen beinhaltet das Ersetzen der Kennung zudem ein Modifizieren der Abbildung, die mit der aktualisierten Kopie der Komponente verknüpft ist.
Des Weiteren beinhaltet das Verfahren 1500 einen Vorgang 1540 des Erzeugens einer modifizierten gepackten Datei. Insbesondere kann der Vorgang 1540 ein Erzeugen einer modifizierten gepackten Datei des Digitalassets 102, die die aktualisierte Kopie der Komponente beinhaltet, implizieren. Bei einer oder mehreren Ausführungsformen impliziert der Vorgang 1540 ein Ersetzen einer älteren gepackten Datei durch eine neuerzeugte gepackte Datei. Bei einigen Ausführungsformen impliziert der Vorgang 1540 das Anhängen der aktualisierten Kopie der Komponente an die gepackte Datei.
Das Verfahren 1500 kann zudem eine Anzahl von zusätzlichen Vorgängen beinhalten. Bei einer oder mehreren Ausführungsformen beinhaltet das Verfahren 1500 zudem einen Vorgang des Entfernens der aktualisierten Kopie der Komponente. Insbesondere kann dieser Vorgang das Entfernen der aktualisierten Kopie der Komponente aus der Datenbank 214 beim Erzeugen der modifizierten gepackten Datei beinhalten. Bei einer oder mehreren Ausführungsformen impliziert dieser Vorgang das Synchronisieren der aktualisierten Kopie der Komponente des Digitalassets und des modifizierten Manifests auf einer Cloudspeichervorrichtung vor dem Erzeugen der modifizierten gepackten Datei.
Bei einigen Ausführungsformen beinhaltet das Verfahren 1500 zudem die Vorgänge des Anzeigens des Digitalassets als monolithische Datei innerhalb einer ersten Anwendung auf Grundlage dessen, dass die erste Anwendung auf die gepackte Datei des Digitalassets zugreift; des gegenüber der ersten Anwendung erfolgenden Anzeigens, dass das Digitalasset von einer zweiten Anwendung modifiziert worden ist, was bewirkt, dass die erste Anwendung auf die modifizierte gepackte Datei zugreift; und des Aktualisierens der Anzeige innerhalb der ersten Anwendung zur Anzeige des modifizierten Digitalassets auf Grundlage dessen, dass die erste Anwendung auf die modifizierte gepackte Datei zugreift. Zusätzlich wird die Anzeige automatisch ohne Nutzerinteraktion aktualisiert.
Der Begriff „Digitalumgebung“ bezeichnet im Sinne des Vorliegenden allgemein eine Umgebung, die beispielsweise auf einer eigenständigen (stand-alone) Anwendung (beispielsweise einem PC oder einer Mobilanwendung, die auf einer Rechenvorrichtung läuft), als Teil einer Anwendung, als Plug-in für eine Anwendung, als Bibliotheksfunktion oder Funktionen, als Servervorrichtung und/oder als Cloudrechensystem implementiert ist. Eine Digitalmedienumgebung ermöglicht, dass das Digitalassetsynchronisierungssystem eine Digitalassetverwaltung und Synchronisierung zwischen Rechenvorrichtungen und über diese hinweg ermöglicht.
Ausführungsformen der vorliegenden Offenbarung können Spezialzweck- oder Allzweckcomputer beinhalten oder nutzen, die Computerhardware, so beispielsweise einen oder mehrere Prozessoren und einen Systemspeicher, beinhalten, wie nachstehend noch detaillierter erläutert wird. Ausführungsformen innerhalb des Umfangs der vorliegenden Offenbarung beinhalten zudem physische und andere computerlesbare Medien zum Tragen oder Speichern von computerausführbaren Anweisungen und/oder Datenstrukturen. Insbesondere können ein oder mehrere der hier beschriebenen Prozesse wenigstens teilweise als Anweisungen implementiert sein, die in einem nichttemporären computerlesbaren Medium verkörpert und durch eine oder mehrere Rechenvorrichtungen (beispielsweise beliebige der Mediencontentzugriffsvorrichtungen, die hier beschrieben sind) ausführbar sind. Im Allgemeinen empfängt ein Prozessor (beispielsweise ein Mikroprozessor) Anweisungen von einem nichttemporären computerlesbaren Medium (beispielsweise einem Speicher und dergleichen) und führt diese Anweisungen aus, wodurch ein oder mehrere Prozesse, darunter einer oder mehrere der hier beschriebenen Prozesse, durchgeführt werden.
Computerlesbare Medien können beliebige verfügbare Medien sein, auf die von einem Allzweck- oder Spezialzweckcomputersystem zugegriffen werden kann. Computerlesbare Medien, die computerausführbare Anweisungen speichern, sind nichttemporäre computerlesbare Speichermedien (Vorrichtungen). Computerlesbare Medien, die computerausführbare Anweisungen tragen, sind Übertragungsmedien. Beispiels- und nicht beschränkungshalber können Ausführungsformen der Offenbarung wenigstens zwei getrennte, verschiedene Arten von computerlesbaren Medien beinhalten, nämlich nichttemporäre computerlesbare Speichermedien (Vorrichtungen) und Übertragungsmedien.
Nichttemporäre computerlesbare Speichermedien (Vorrichtungen) beinhalten RAM, ROM, EEPROM, CD-ROM, Festkörperlaufwerke, Flash-Speicher, Phasenänderungsspeicher, andere Arten von Speichern, andere optische Plattenspeicher, magnetische Plattenspeicher oder andere magnetische Speichervorrichtungen, oder ein beliebiges anderes Medium, das zum Speichern von gewünschten Programmcodemitteln in Form von computerausführbaren Anweisungen oder Datenstrukturen genutzt wird und auf das von einem Allzweck- oder Spezialzweckcomputer zugegriffen werden kann.
Computerausführbare Anweisungen beinhalten beispielsweise Anweisungen und Daten, die bei Ausführung durch einen Prozessor veranlassen, dass ein Allzweckcomputer, ein Spezialzweckcomputer oder eine Spezialzweckverarbeitungsvorrichtung eine bestimmte Funktion oder eine bestimmte Gruppe von Funktionen wahrnehmen. Bei einigen Ausführungsformen führt ein Allzweckcomputer computerausführbare Anweisungen aus, um einen Allzweckcomputer in einen Spezialzweckcomputer umzuwandeln, der Elemente der Offenbarung implementiert. Die computerausführbaren Anweisungen können beispielsweise Binaries, Anweisungen in einem Zwischenformat, so beispielsweise in Assemblersprache, oder sogar Sourcecode sein. Obwohl der Erfindungsgegenstand in einer Sprache beschrieben worden ist, die für strukturelle Merkmale und/oder Verfahren spezifisch ist, sollte einsichtig sein, dass der in den beigefügten Ansprüchen definierte Erfindungsgegenstand nicht unbedingt auf die vorbeschriebenen Merkmale oder Vorgänge beschränkt ist. Vielmehr sind die beschriebenen Merkmale und Vorgänge als exemplarische Formen der Implementierung der Ansprüche offenbart.
16 zeigt ein Blockdiagramm einer exemplarischen Rechenvorrichtung 1600, die dafür ausgelegt sein kann, einen oder mehrere der vorbeschriebenen Prozesse durchzuführen. Es sollte einsichtig sein, dass eine oder mehrere Rechenvorrichtungen, so beispielsweise die Rechenvorrichtung 1600, die vorbeschriebenen Clientvorrichtungen und Servervorrichtungen darstellen kann. Bei einer oder mehreren Ausführungsformen kann die Rechenvorrichtung 1600 eine Mobilvorrichtung (beispielsweise ein Mobiltelefon, ein Smartphone, ein PDA, ein Tablet, ein Laptop, eine Kamera, ein Tracker, eine Armbanduhr, eine tragbare Vorrichtung und dergleichen mehr) sein. Bei einigen Ausführungsformen kann die Rechenvorrichtung 1600 eine nichtmobile Vorrichtung (beispielsweise ein Desktopcomputer oder ein anderer Typ von Clientvorrichtung) sein. Des Weiteren kann die Rechenvorrichtung 1600 eine Servervorrichtung sein, die cloudbasierte Verarbeitungs- und Speicherkapazitäten beinhaltet.
Wie in 16 gezeigt ist, kann die Rechenvorrichtung 1600 einen oder mehrere Prozessoren 1602, einen Speicher 1604, eine Ablagevorrichtung 1606, I/O-Schnittstellen (I/O Input/Output) 1608 und eine Kommunikationsschnittstelle 1610, die mittels einer Kommunikationsinfrastruktur (beispielsweise mittels eines Busses 1612) kommunikativ gekoppelt sind, beinhalten. Obwohl in 16 die Rechenvorrichtung 1600 gezeigt ist, sollen die in 16 dargestellten Komponenten nicht beschränkend sein. Zusätzliche oder alternative Komponenten können bei anderen Ausführungsformen verwendet werden. Bei bestimmten Ausführungsformen beinhaltet die Rechenvorrichtung 1600 beispielsweise weniger Komponenten, als in 16 gezeigt ist. Komponenten der Rechenvorrichtung 1600, die in 16 gezeigt sind, werden nunmehr detaillierter beschrieben.
Bei bestimmten Ausführungsformen beinhaltet/beinhalten der Prozessor / die Prozessoren 1602 Hardware zum Ausführen von Anweisungen, so beispielsweise von solchen, die ein Computerprogramm bilden. Beispiels- und nicht beschränkungshalber kann/können der Prozessor / die Prozessoren 1602 zur Ausführung von Anweisungen die Anweisungen aus einem internen Register, einem internen Cache, einem Speicher 1604 oder einer Speichervorrichtung 1606 abrufen (oder holen) und diese decodieren und ausführen.
Die Rechenvorrichtung 1600 beinhaltet den Speicher 1604, der mit dem Prozessor / den Prozessoren 1602 gekoppelt ist. Der Speicher 1604 kann zum Speichern von Daten, Metadaten und Programmen zur Ausführung durch den Prozessor / die Prozessoren verwendet werden. Der Speicher 1604 kann einen oder mehrere flüchtige und nichtflüchtige Speicher beinhalten, so beispielsweise einen Speicher mit wahlfreiem Zugriff („RAM“), einen Nur-Lese-Speicher („ROM“), eine Festkörperplatte („SSD“), einen Flash, einen Phasenänderungsspeicher („PCM“) oder andere Typen von Datenspeicher. Der Speicher 1604 kann ein interner oder ein verteilter Speicher sein.
Die Rechenvorrichtung 1600 beinhaltet eine Speichervorrichtung 1606, die wiederum einen Speicher zum Speichern von Daten oder Anweisungen beinhaltet. Beispiels- und nicht beschränkungshalber kann die Speichervorrichtung 1606 das vorbeschriebene nichttemporäre Speichermedium beinhalten. Die Speichervorrichtung 1606 kann ein Festplattenlaufwerk (HDD), einen Flash-Speicher, ein USB-Laufwerk (Universeller Serieller Bus USB) oder eine Kombination aus diesen oder anderen Speichervorrichtungen beinhalten.
Wie gezeigt ist, beinhaltet die Rechenvorrichtung 1600 eine oder mehrere I/O-Schnittstellen 1608, die dafür bereitgestellt sind zu ermöglichen, dass ein Nutzer eine Eingabe (beispielsweise Nutzerstriche) für die Rechenvorrichtung 1600 bereitstellt, eine Ausgabe von dieser empfängt oder auf andere Weise Daten an diese oder von dieser überträgt. Die I/O-Schnittstellen 1608 können eine Maus, ein Touchpad oder eine Tastatur, einen Touchscreen bzw. einen berührungsempfindlichen Bildschirm, eine Kamera, einen optischen Scanner, eine Netzwerkschnittstelle, ein Modem, andere bekannte I/O-Vorrichtungen oder eine Kombination aus derartigen I/O-Schnittstellen 1608 beinhalten. Der Touchscreen kann mit einem Stift oder Finger aktiviert werden.
Die I/O-Schnittstellen 1608 können eine oder mehrere Vorrichtungen beinhalten, die einem Nutzer eine Ausgabe präsentieren, darunter unter anderem eine Grafikengine, eine Anzeige (beispielsweise einen Anzeigebildschirm), einen oder mehrere Ausgabetreiber (beispielsweise Anzeigetreiber), einen oder mehrere Audiolautsprecher und einen oder mehrere Audiotreiber. Bei bestimmten Ausführungsformen sind die I/O-Schnittstellen 1608 dafür ausgelegt, grafische Daten für eine Anzeige zur Präsentation gegenüber einem Nutzer bereitzustellen. Die grafischen Daten können eine oder mehrere grafische Nutzerschnittstellen und/oder einen anderen grafischen Content, so er bei einer bestimmten Implementierung erforderlich ist, darstellen.
Die Rechenvorrichtung 1600 kann des Weiteren eine Kommunikationsschnittstelle 1610 beinhalten. Die Kommunikationsschnittstelle 1610 kann Hardware, Software oder beides beinhalten. Die Kommunikationsschnittstelle 1610 stellt eine oder mehrere Schnittstellen zur Kommunikation (beispielsweise einer paketbasierten Kommunikation) zwischen der Rechenvorrichtung und einer oder mehreren anderen Rechenvorrichtungen oder einem oder mehreren Netzwerken bereit. Beispiels- und nicht beschränkungshalber kann die Kommunikationsschnittstelle 1610 einen Netzwerkschnittstellencontroller (NIC) oder einen Netzwerkadapter für die Kommunikation mit einem Ethernet oder einem anderen drahtbasierten Netzwerk oder auch einen drahtlosen NIC (WNIC) oder einen Drahtlosadapter für die Kommunikation mit einem Drahtlosnetzwerk, so beispielsweise einem Wi-Fi, beinhalten. Die Rechenvorrichtung 1600 kann des Weiteren einen Bus 1612 beinhalten. Der Bus 1612 kann Hardware, Software oder beides beinhalten, wodurch die Komponenten der Rechenvorrichtung 1600 miteinander gekoppelt werden.
In der vorstehenden Beschreibung ist die Erfindung anhand spezifischer exemplarischer Ausführungsformen beschrieben worden. Verschiedene Ausführungsformen und Aspekte der Erfindung/Erfindungen sind anhand der hier erläuterten Details beschrieben worden, wobei die begleitende Zeichnung die verschiedenen Ausführungsformen illustriert. Die vorstehende Beschreibung und die Zeichnung illustrieren die Erfindung und sollen nicht erfindungsbeschränkend gedeutet werden. Es sind zahlreiche spezifische Details beschrieben, um ein eingehendes Verständnis der verschiedenen Ausführungsformen der vorliegenden Erfindung zu ermöglichen.
Die vorliegende Erfindung kann auch in anderen spezifischen Formen verkörpert sein, ohne von ihrem Wesen oder ihren wesentlichen Eigenschaften abzugehen. Die beschriebenen Ausführungsformen sollen in jeder Hinsicht als illustrativ und nicht als restriktiv betrachtet werden. Die hier beschriebenen Verfahren können beispielsweise mit weniger oder mehr Schritten/Vorgängen durchgeführt werden, oder es können die Schritte/Vorgänge in anderen Reihenfolgen durchgeführt werden. Zusätzlich können die hier beschriebenen Schritte/Vorgänge wiederholt oder parallel zueinander oder parallel zu anderen Instanzen derselben oder ähnlicher Schritte/Vorgänge durchgeführt werden. Der Umfang der Erfindung ist daher durch die beigefügten Ansprüche und nicht durch die vorstehende Beschreibung angegeben. Alle Änderungen, die der Bedeutung und dem Äquivalenzbereich der Ansprüche entsprechen, sollen in ihrem Umfang enthalten sein.

Claims

Computerimplementiertes Verfahren zum Bereitstellen von synchronisierten Digitalassets auf einer Rechenvorrichtung in einer Digitalmedienumgebung zum Durchführen einer Digitalassetverwaltung zwischen der Rechenvorrichtung und einem Cloudspeichermedium, wobei das Verfahren umfasst: auf einer Clientvorrichtung erfolgendes Vorhalten einer Datenbank mit einer Digitalassetabbildung, die angibt, wo Komponenten, die ein Digitalasset bilden, innerhalb der Datenbank gespeichert sind, wobei die Komponenten als unabhängige Dateien, die über die Datenbank verteilt sind, gespeichert sind; auf der Clientvorrichtung erfolgendes Erzeugen einer gepackten Datei des Digitalassets, die eine Kopie einer jeden der Komponenten des Digitalassets umfasst; und Erzeugen einer aktualisierten Digitalassetabbildung zur Angabe dessen, dass die Komponenten des Digitalassets innerhalb der gepackten Datei gespeichert sind.
Verfahren nach Anspruch 1, des Weiteren umfassend: Erzeugen eines Digitalassetmanifests, das die Komponenten mit dem Digitalasset verknüpft; Synchronisieren der Komponenten des Digitalassets und des Digitalassetmanifests auf einer Cloudspeichervorrichtung vor dem Erzeugen der gepackten Datei des Digitalassets; und nach dem Aktualisieren der Digitalassetabbildung erfolgendes Entfernen der Komponenten, die als unabhängige Dateien, die über die Datenbank verteilt sind, gespeichert sind, aus der Datenbank.
Verfahren nach Anspruch 2, des Weiteren umfassend: Detektieren einer Modifikation an einer Komponente des Digitalassets; in der Datenbank und in Reaktion auf das Detektieren der Modifikation an der Komponente erfolgendes Speichern einer aktualisierten Kopie der Komponente, die die detektierten Modifikationen an der Komponente beinhaltet; Modifizieren der gepackten Datei des Digitalassets derart, dass diese die aktualisierte Kopie der Komponente beinhaltet; und Entfernen der aktualisierten Kopie der Komponente aus der Datenbank beim Modifizieren der gepackten Datei.
Verfahren nach Anspruch 3, des Weiteren umfassend: innerhalb des Digitalassetmanifests und nach dem Speichern der aktualisierten Kopie der Komponente erfolgendes Ersetzen einer Kennung, die die Komponente mit dem Digitalasset verknüpft, durch eine Kennung, die die aktualisierte Kopie der Komponente mit dem Digitalasset verknüpft; und beim Modifizieren der gepackten Datei erfolgendes Aktualisieren der modifizierten Digitalassetabbildung zur Wiedergabe dessen, dass die aktualisierte Kopie der Komponente als Teil der modifizierten gepackten Datei gespeichert ist.
Verfahren nach Anspruch 3 oder 4, des Weiteren umfassend: Detektieren der Modifikation an der Komponente des Digitalassets in einer Anwendung, die auf der Clientvorrichtung befindlich ist, wobei die Anwendung die gepackte Datei des Digitalassets als monolithische Datei anzeigt.
Verfahren nach Anspruch 5, des Weiteren umfassend: von der Anwendung her erfolgendes Empfangen einer Inter-Prozess-Kommunikation zur Angabe dessen, dass eine oder mehrere Komponenten des Digitalassets modifiziert worden sind.
Verfahren nach einem der Ansprüche 3 bis 6, des Weiteren umfassend: Detektieren der Modifikation an der Komponente des Digitalassets auf Grundlage des Empfangens der aktualisierten Kopie der Komponente von der Cloudspeichervorrichtung.
Verfahren nach einem der Ansprüche 3 bis 7, des Weiteren umfassend: Synchronisieren der aktualisierten Kopie der Komponente mit der Cloudspeichervorrichtung vor dem Modifizieren der gepackten Datei des Digitalassets ohne Synchronisieren anderer nichtmodifizierter Komponenten des Digitalassets; und Entfernen der aktualisierten Kopie der Komponente aus der Datenbank.
Verfahren nach einem der Ansprüche 3 bis 8, wobei das Erzeugen der gepackten Datei des Digitalassets umfasst: Komprimieren einer jeden der Komponenten des Digitalassets in die gepackte Datei.
Verfahren nach Anspruch 9, wobei das Modifizieren der gepackten Datei des Digitalassets derart, dass diese die aktualisierte Kopie der Komponente beinhaltet, umfasst: Erzeugen einer zusätzlichen gepackten Datei des Digitalassets, die die aktualisierte Kopie der Komponente anstelle der Komponente beinhaltet; und Entfernen der gepackten Datei von der Clientvorrichtung.
Verfahren nach Anspruch 9 oder 10, wobei das Modifizieren der gepackten Datei des Digitalassets derart, dass diese die aktualisierte Kopie der Komponente beinhaltet, umfasst: Anhängen einer komprimierten Kopie der aktualisierten Kopie der Komponente an die gepackte Datei, um die modifizierte gepackte Datei zu erstellen; und Entfernen der gepackten Datei von der Clientvorrichtung beim Erstellen der modifizierten gepackten Datei einschließlich eines Entfernens der Komponente von der Clientvorrichtung.
Verfahren nach Anspruch 11, des Weiteren umfassend: Bestimmen zum Erzeugen einer zusätzlichen gepackten Datei auf Grundlage dessen, dass eine Redundanzschwelle überschritten wird, wobei die Redundanzschwelle überschritten wird, wenn die gepackte Datei als Ergebnis des Anhängens einer oder mehrerer modifizierter Komponenten an die gepackte Datei eine Schwellenanzahl von veralteten Komponenten beinhaltet.
Verfahren nach Anspruch 12, wobei die Schwellenmenge ein Daten-GrößenVerhältnis oder ein Anzahlverhältnis von veralteten Komponenten zu aktuellen Komponenten ist.
Verfahren nach einem der Ansprüche 2 bis 13, des Weiteren umfassend: Überwachen von Digitalassets, die in einem überwachten Dateiverzeichnis der Clientvorrichtung befindlich sind, wobei jedes der Digitalassets innerhalb des überwachten Dateiverzeichnisses in der Datenbank registriert und mit der Cloudspeichervorrichtung synchronisiert wird.
Verfahren nach einem der Ansprüche 2 bis 14, wobei die Datenbank ein oder mehrere vorherige Digitalassetmanifeste des Digitalassets enthält, wobei jedes vorherige Digitalassetmanifest einer vorherigen Version des Digitalassets entspricht und wobei eine oder mehrere Komponenten, die verschiedenen Versionen des Digitalassets entsprechen, auf der Cloudspeichervorrichtung vorgehalten werden.
System zum Bereitstellen einer effizienten Synchronisierung von Digitalassets, wobei das System umfasst: einen oder mehrere computerlesbare Speicher, die eine Datenbank mit einem Manifest beinhalten, das Komponenten, die ein Digitalasset bilden, identifiziert, wobei jede der Komponenten des Digitalassets in einer gepackten Datei gespeichert ist und wobei jede Komponente innerhalb des Digitalassets eine vordefinierte Grenze aufweist, die modifizierbar ist, ohne andere Komponenten des Digitalassets zu beeinflussen; und eine Rechenvorrichtung, auf der Anweisungen gespeichert sind, die bei Ausführung durch die Rechenvorrichtung das System veranlassen zum: Detektieren einer Modifikation an einer Komponente des Digitalassets; in der Datenbank und in Reaktion auf das Detektieren der Modifikation an der Komponente erfolgenden Erstellen einer aktualisierten Kopie der Komponente, die die detektierten Modifikationen an der Komponente beinhaltet; in dem Manifest erfolgenden Ersetzen einer Kennung, die die Komponente mit dem Digitalasset verknüpft, durch eine Kennung, die die aktualisierte Kopie der Komponente mit dem Digitalasset verknüpft; und Erzeugen einer modifizierten gepackten Datei des Digitalassets, die die aktualisierte Kopie der Komponente beinhaltet.
System nach Anspruch 16, auf dem des Weiteren Anweisungen umfasst sind, die bei Ausführung durch die Rechenvorrichtung das System veranlassen zum: Anzeigen des Digitalassets als monolithische Datei innerhalb einer ersten Anwendung auf Grundlage dessen, dass die erste Anwendung auf die gepackte Datei des Digitalassets zugreift; gegenüber der ersten Anwendung erfolgenden Angeben, dass das Digitalasset durch eine zweite Anwendung modifiziert worden ist, was bewirkt, dass die erste Anwendung auf die modifizierte gepackte Datei zugreift; und Aktualisieren der Anzeige innerhalb der ersten Anwendung zur Anzeige eines modifizierten Digitalassets auf Grundlage dessen, dass die erste Anwendung auf die modifizierte gepackte Datei zugreift, wobei die Anzeige automatisch ohne Nutzerinteraktion aktualisiert wird.
System nach Anspruch 16 oder 17, auf dem des Weiteren Anweisungen umfasst sind, die bei Ausführung durch die Rechenvorrichtung das System veranlassen zum: Entfernen der aktualisierten Kopie der Komponente aus der Datenbank beim Erzeugen der modifizierten gepackten Datei.
Computerimplementiertes Verfahren zum Bereitstellen von Digitalassets auf einer Rechenvorrichtung in einer Digitalmedienumgebung zum Durchführen einer Digitalassetverwaltung zwischen der Rechenvorrichtung und einem Cloudspeichermedium, wobei das Verfahren umfasst: von einem Cloudspeichersystem erfolgendes Empfangen eines Teilsatzes von Komponenten eines Digitalassets; auf einer Clientvorrichtung erfolgendes Durchführen eines Schrittes des Vorhaltens einer Speicherung des Teilsatzes von Komponenten zwischen einer Komponentendatenbank und einer gepackten Datei, wobei die Komponentendatenbank Komponenten umfasst, die als unabhängige Dateien über die Clientvorrichtung hinweg gespeichert sind; und innerhalb eines Dateiverzeichnisses der Clientvorrichtung erfolgendes Bereitstellen des Digitalassets für einen Nutzer als eine einzige monolithische Datei auf Grundlage der gepackten Datei.
Verfahren nach Anspruch 19, wobei das Durchführen des Schrittes des Vorhaltens einer Speicherung des Teilsatzes von Komponenten umfasst: von der Clientvorrichtung erfolgendes Entfernen des Teilsatzes von Komponenten aus der Komponentendatenbank nach dem Erzeugen der gepackten Datei.