{"id":280,"date":"2013-04-09T14:47:33","date_gmt":"2013-04-09T14:47:33","guid":{"rendered":"http:\/\/www.hardturm.ch\/luz\/?p=280"},"modified":"2013-04-09T14:51:38","modified_gmt":"2013-04-09T14:51:38","slug":"wir-brauchen-eine-offene-sync-infrastruktur","status":"publish","type":"post","link":"https:\/\/hardturm.ch\/luz\/2013\/04\/wir-brauchen-eine-offene-sync-infrastruktur\/","title":{"rendered":"Wir brauchen eine offene Sync-Infrastruktur!"},"content":{"rendered":"<p><em>tl;dr: Einen Ansatz gibt es &#8211; bauen wir <a title=\"Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV)\" href=\"http:\/\/tools.ietf.org\/html\/rfc6578\" target=\"_blank\">RFC 6578<\/a> in <a title=\"mod_dav\" href=\"http:\/\/webdav.org\/mod_dav\/\" target=\"_blank\">mod_dav<\/a> ein!<\/em><\/p>\n<p>Nach einem <a title=\"Apple's broken promise: why doesn't iCloud 'just work'?\" href=\"http:\/\/www.theverge.com\/2013\/3\/26\/4148628\/why-doesnt-icloud-just-work\" target=\"_blank\">deutlichen Artikel auf the Verge<\/a> hat sich in den letzten Wochen auch auf breiterer Front die Erkenntnis duchgesetzt, dass die iCloud ihr Versprechen vom m<em>agischen Sync<\/em> definitiv nicht eingel\u00f6st hat.<\/p>\n<p>Andererseits zeigte die einigermassen unerwartete <a title=\"Powering Down Google Reader\" href=\"http:\/\/googlereader.blogspot.de\/2013\/03\/powering-down-google-reader.html\" target=\"_blank\">Abk\u00fcndigung von Google Reader<\/a>, wie schnell eine &#8220;Infrastruktur&#8221; wegbrechen kann, wenn es sich eben nicht wirklich um Infrastruktur, sondern nur um ein Projektchen einer Firma wie Google handelt, die, aus was f\u00fcr Gr\u00fcnden auch immer, dessen \u00fcberdr\u00fcssig wurde.<\/p>\n<p><strong>Das Gute an diesen Ereignissen ist &#8211; es wird klarer: wir brauchen eine Infrastruktur f\u00fcr Sync. Basierend auf Standards, mit offener Implementation, und nicht abh\u00e4ngig von einem bestimmten Provider.<\/strong><\/p>\n<p>Sync l\u00e4sst sich grob in zwei Aufgaben unterteilen:<\/p>\n<ul>\n\n<li>Eine effiziente Verteilung (insbesondere was Datentransfer anbelangt) der produzierten Daten an alle Teilnehmer<\/li>\n\n<li>Das konsistente Zusammenf\u00fchren der Daten von verschiedenen Beteiligten zu &#8220;einer Wahrheit&#8221;<\/li>\n<\/ul>\n<p>Wie schwierig die zweite Aufgabe ist,kommt nur darauf an, was man will. Apple wollte nichts weniger als die K\u00f6nigsl\u00f6sung und nahm sich vor, komplexe Objektgraphen (CoreData) generisch zu synchronisieren. Das haben sie vorerst nicht mit einer brauchbaren Stabilit\u00e4t geschafft.<\/p>\n<p>Will man aber &#8220;nur&#8221; einen Haufen Files \u00fcberall im Zugriff, wie Dropbox, dann ist die zweite Aufgabe fast trivial, und alles viel einfacher. Der reine File-Sync funktioniert ja scheinbar sogar in der iCloud ganz gut.<\/p>\n<p>F\u00fcr die meisten Apps liegt der Aufwand f\u00fcr die Ermittlung einer <em>in ihrem Kontext ausreichend konsistenten<\/em> &#8220;Wahrheit&#8221; irgendwo dazwischen. Es w\u00e4re sch\u00f6n, wenn es da mit der Zeit bequeme Frameworks f\u00fcr diesen oder jenen Anwendungsfall g\u00e4be, aber zu einer generischen Sync-Infrastruktur geh\u00f6rt dieser Teil <em>nicht<\/em>.<\/p>\n<p><strong>Der erste Aufgabe hingegen ist von der Sync-Infrastruktur zu erf\u00fcllen, die man von ganz klein auf dem eigenen Server installiert bis hin zu ganz gross skaliert bei einem Cloud-Anbieter betreiben k\u00f6nnen m\u00f6chte. Genauso simpel, zuverl\u00e4ssing und austauschbar wie ein Webserver.<\/strong><\/p>\n<p>Es braucht dazu nicht nur einen Server, denn als App-Enwickler m\u00f6chte man nicht die Files irgendwo abholen m\u00fcssen, nicht Verzeichnisb\u00e4ume nach \u00c3\u201enderungen durchscannen. Sondern lokal ein Abbild der Daten haben, und benachrichtigt werden, wenn sich etwas \u00e4ndert (analog dazu, wie kaum jemand direkt TCP-Sockets aufmachen will, um HTTP zu sprechen). Dazu braucht es ein passendes Client-Framework.<\/p>\n<p>Dropbox nutzt jetzt die Gunst der Stunde, genau so ein Framework mit <a title=\"Dropbox Sync API\" href=\"https:\/\/www.dropbox.com\/developers\/sync\" target=\"_blank\">seinem neuen Sync-SDK<\/a> anzubieten. Aber eine Standard-basierte offene Infrastruktur ist das nicht.<\/p>\n<p><strong>Offen und standardisiert hingegen ist <a title=\"WebDAV\" href=\"http:\/\/de.wikipedia.org\/wiki\/WebDAV\" target=\"_blank\">WebDAV<\/a> (<a title=\"HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)\" href=\"http:\/\/tools.ietf.org\/html\/rfc4918\" target=\"_blank\">RFC 4918<\/a>).<\/strong> Und in der Tat nutzen es <a title=\"More about our Cloud Sync\" href=\"http:\/\/vemedio.com\/blog\/posts\/more-about-our-cloud-sync\" target=\"_blank\">einige App-Entwickler bereits f\u00fcr ihren Sync-Bedarf<\/a>. WebDAV hat aber ein Problem im Zusammenhang mit Sync &#8211; es ist bei einer gr\u00f6sseren Anzahl von Objekten (Files) nicht effizient, \u00c3\u201enderungen zu finden.<\/p>\n<p><strong>Es sei denn, man h\u00e4tte eine Implementation von <a title=\"Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV)\" href=\"http:\/\/tools.ietf.org\/html\/rfc6578\" target=\"_blank\">RFC 6578<\/a><\/strong>: &#8220;Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV)&#8221;.<\/p>\n<p>Wer hat eine? Apple. Warum? Weil sie das in der iCloud brauchen. Das ist vielleicht momentan nicht gerade die beste Werbung. Aber wer sich in Apple-Technologien ein bisschen auskennt, weiss, dass Apple genau dieses Muster viele Male sehr erfolgreich angewendet hat: solide Standards nehmen, offen weiterentwickeln, und dann als Basis f\u00fcr propriet\u00e4re &#8220;Magic&#8221; benutzen (z.B. <a title=\"HTTP Live Streaming\" href=\"http:\/\/en.wikipedia.org\/wiki\/HTTP_Live_Streaming\" target=\"_blank\">HTTP Live Streaming<\/a>, <a title=\"Bonjour\" href=\"http:\/\/en.wikipedia.org\/wiki\/Bonjour_(software)\" target=\"_blank\">Bonjour<\/a>\/<a title=\"Multicast DNS\" href=\"http:\/\/tools.ietf.org\/html\/rfc6762\" target=\"_blank\">multicast DNS<\/a>, <a title=\"CalDAV\" href=\"http:\/\/de.wikipedia.org\/wiki\/CalDAV\" target=\"_blank\">CalDAV<\/a>). Ich bin \u00fcberzeugt, dass WebDAV Collection Sync <em>nicht<\/em> das Problem in der iCloud ist.<\/p>\n<p>Mein Fazit:<\/p>\n<p><strong>Wir (damit meine ich die Indie-Dev Community) sollten Kr\u00e4fte b\u00fcndeln, RFC 6578 einerseits in <a title=\"mod_dav\" href=\"http:\/\/webdav.org\/mod_dav\/\" target=\"_blank\">mod_dav<\/a> implementiert zu bekommen und so in n\u00fctzlicher Frist auf jeden Apache-Webserver dieses Planeten auszurollen. Und am anderen Ende Sync-Frameworks zu bauen, die genau dasselbe bieten wie die neue Dropbox Sync-API, aber mit WebDAV als Backend.<\/strong><\/p>\n<p>Damit nicht nur wir Entwickler, sondern auch die Anwender unserer Apps wieder w\u00e4hlen k\u00f6nnen, bei wem die Daten liegen sollen.<\/p>\n<p>Ist die Zeit endlich reif daf\u00fcr?<\/p>","protected":false},"excerpt":{"rendered":"<p>tl;dr: Einen Ansatz gibt es &#8211; bauen wir RFC 6578 in mod_dav ein! Nach einem deutlichen Artikel auf the Verge hat sich in den letzten Wochen auch auf breiterer Front die Erkenntnis duchgesetzt, dass die iCloud ihr Versprechen vom magischen Sync definitiv nicht eingel\u00f6st hat. Andererseits zeigte die einigermassen unerwartete Abk\u00fcndigung von Google Reader, wie &hellip; <a href=\"https:\/\/hardturm.ch\/luz\/2013\/04\/wir-brauchen-eine-offene-sync-infrastruktur\/\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">Wir brauchen eine offene Sync-Infrastruktur!<\/span><\/a><\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[12,10],"class_list":["post-280","post","type-post","status-publish","format-standard","hentry","category-deutsch","tag-cloud","tag-sync"],"_links":{"self":[{"href":"https:\/\/hardturm.ch\/luz\/wp-json\/wp\/v2\/posts\/280","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hardturm.ch\/luz\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hardturm.ch\/luz\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hardturm.ch\/luz\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hardturm.ch\/luz\/wp-json\/wp\/v2\/comments?post=280"}],"version-history":[{"count":38,"href":"https:\/\/hardturm.ch\/luz\/wp-json\/wp\/v2\/posts\/280\/revisions"}],"predecessor-version":[{"id":318,"href":"https:\/\/hardturm.ch\/luz\/wp-json\/wp\/v2\/posts\/280\/revisions\/318"}],"wp:attachment":[{"href":"https:\/\/hardturm.ch\/luz\/wp-json\/wp\/v2\/media?parent=280"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hardturm.ch\/luz\/wp-json\/wp\/v2\/categories?post=280"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hardturm.ch\/luz\/wp-json\/wp\/v2\/tags?post=280"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}