De:Changing the URL of a calendar
Die direkte Änderung der URL eines Kalenders ist keine triviale Operation.
Eine Implementierung dieses Features muss jede Eventualität korrekt behandeln. Die Datenkonsistenz sicherzustellen ist sehr aufwendig.
Als ein einfaches Beispiel sei der Wechsel auf SSL genannt, sprich anstelle über http:// wird nun über https:// zugegriffen. Es könnte sich im Extremfall um einen komplett anderen Server handeln.
Andere Nutzer möchten mit dieser Funktion den Server wechseln. In so einem Fall müsste die App fähig sein, die Kalender auf dem neuen Server zuzuordnen. Dies ist schwierig, falls die Listen sich komplett unterscheiden.
Auch vorstellbar ist der Fall, dass die beiden Kalender nicht mehr synchron sind. Eine Duplizierung oder eine Vermischung der Termine kann im Extremfall so ärgerlich wie ein Komplettverlust der Daten sein.
Eine Analogie: Man stelle sich vor, der Benutzer liest in einem Buch. Während des Lesens möchte man dieses Buch nun gegen ein anderes austauschen. Im besten Fall handelt es sich genau um das selbe Buch mit der selben Ausgabe, der selben geöffneten Seite, der selben Schriftgröße und überhaupt des exakt selben Aufbaus. Schon eine kleine Änderung erfordert ein Nachjustieren. Ist zum Beispiel die falsche Seite aufgeschlagen, so muss man erst umblättern. Unterscheidet sich die Auflage, dann muss man unter Umständen die Stelle erst suchen, an der man aufgehört hat zu lesen, vielleicht ist sie auch gar nicht mehr vorhanden. Im Extremfall handelt es sich sogar um ein ganz anderes Buch, wodurch man den metaphorischen roten Faden verliert. Die Vielzahl der möglichen Probleme ist nahezu unbegrenzt.
Hingegen ist der Aufwand um sein Konto einzurichten vergleichsweise gering. Sollte der Nutzer, entgegen aller Erwartungen, häufiger die URL wechseln müssen, so bietet die App Auto-Provisioning an ( http://dmfs.org/wiki/index.php?title=Auto-provisioning ). Dieses Feature wird in Zukunft weiter verbessert und ausgebaut.
Die Möglichkeit der Änderung der URL steht dennoch auf unserer TODO-Liste. Sie hat aus Zeitgründen aber eine geringe Priorität, zumal es hierfür eine alternative Lösungsmöglichkeit gibt. Desweiteren, wollen wir sicherstellen, dass die Implementierung, wie anfänglich erwähnt, keine Fehler enthält. Die Sicherheit und Unversehrtheit der Daten genießt an dieser Stelle höchste Priorität.
