git.marmaro.de Git - krt-msg/blob - 2013-03-16T19:57:20.00Z.msg

   1 From: Boris Kraut <krt@nurfuerspam.de>\r
   2 Date: Sat, 16 Mar 2013 20:57:20 +0100\r
   3 Category: \r
   4 Message-ID: <20130316205720.V9bcVR@silberbruch>\r
   5 Organization: \r
   6 Keywords: \r
   7 Comments: \r
   8 To: undisclosed-recipients: ;\r
   9 Subject: [.plan] Synchronisation: Protokolle vs. Dateien\r
  10 \r
  11 Nach einem sehr guten Gespraech mit meillo heute Nachmittag\r
  12 kann ich endlich eine Frage beantworten, die mich bei der\r
  13 ganzen IMAP/Atom/XMPP/WebDAV/CardDAV/CalDAV-Debatte immer\r
  14 noch gestoert hat: Brauchen wir diese Protokolle?\r
  15 \r
  16 Nicht falsch verstehen, ich finde es gut, dass es diese\r
  17 Standards gibt, doch betrachtet man die dazu existierende\r
  18 Software ist klar, dass wir hier Arbeit doppelt machen:\r
  19 Wir spezifizieren nicht nur das Format, wie auszutauschende\r
  20 Daten aussehen sollen, sondern wir legen auch fest, wie\r
  21 dieser Datenaustausch ablaufen soll. Klingt vernuenftig,\r
  22 aber warum muss letzteres fuer jedes Datenformat nochmals\r
  23 definiert werden? Kann man das Problem nicht einmal Loesen\r
  24 und -- bis zum Aufkommen einer besseren Methode -- eben\r
  25 diese Loesungen nutzen?\r
  26 \r
  27   Anmerkung: Zu einem gewissen Grad scheint sich jetzt\r
  28              langsam abzuzeichnen, dass HTTP/WebDAV dieses\r
  29              Universal-Protokoll wird. Die jeweiligen Er-\r
  30              weiterungen machen teilweise Sinn, z.B. bei\r
  31              Terminabfragen, koennten aber auch anders\r
  32              geloest werden. Zudem wuerde ich gern mal\r
  33              mit einem DAV-Experten reden, wie effizient\r
  34              das ganze ist...\r
  35 \r
  36 Die gaengigen Synchronisationsloesungen -- egal ob rsync,\r
  37 svn, git, ... -- arbeiten jedoch auf Dateiebene, was von\r
  38 daher problematisch ist, dass der Standard zwar die Datei-\r
  39 formate festlegt, aber nicht festlegt, ob auf Client-\r
  40 oder Serverseite auch die Datenhaltung in diesen Formaten\r
  41 erfolgt. Meist existiert nur eine Im- und Export funktion,\r
  42 ggf. ueber die dazugehoeren Protokollstandards.\r
  43 \r
  44 Fuer die naechste Zeit will ich jedenfalls versuchen, meine\r
  45 Mails, Kalender und Kontakt per git zu Sychronisieren. Das\r
  46 funktioniert auch mit etwas Bauchgrummeln ueber HTTP und ist\r
  47 daher ebenfalls hinter Zwangsproxies schnell zu erledigen.\r
  48 \r
  49 Uebrigens tut das auch fuer ausgehende Mails. Bei mir gibt\r
  50 es ein Maildir "Outbox", also ein Postausgang. Der MUA ruft\r
  51 also nicht beim Versenden explizit ein Programm wie sendmail\r
  52 auf, sondern legt sie lediglich in outbox/new ab. In einem\r
  53 davon komplett unabhaengigen Vorgang wird per cron diese\r
  54 Outbox geleert. Die Mails werden versendet und anstatt in\r
  55 einem Sent-Ordner der Inbox, in outbox/cur abgelegt.\r
  56 \r
  57 Noch eine kleine Randnotiz: Es gibt Dinge, die IMAPs vir-\r
  58 tuelle Ordner koennen, die mit "echten" Ordnern schwer nach-\r
  59 baubar sind. Anstatt aber diese Limitierung hinzunehmen\r
  60 und eine weitere Abstraktionsschicht einzufuehren, die dann\r
  61 -- database-powered -- das alles kann ist der falsche Weg.\r
  62 Wenn Soft- und Hardlinks nicht reichen, man also deutlich\r
  63 dynamischere Ordner braucht, dann ist das ein Fall fuer das\r
  64 Dateisystem. Dort muessen diese Probleme geloest werden, \r
  65 nicht zig Ebenen drueber.\r