Forum


Spickzettel

Neben den Buttons stehen unter anderem folgende BB-Codes zur Verfügung:

Bildgröße beschränken:
[img width=400 height=300]Bildadresse[/img]
Weglassen von height o. width behält Bildverhältnis bei.

Tabelle:
[table]
[tr][td]Zelle 1/1[/td][td]Zelle 1/2[/td][/tr]
[tr][td]Zelle 2/1[/td][td]Zelle 2/2[/td][/tr]
[/table]
[tr] = Zeile [td] = Zelle

Text:
[u]unterstreichen[/u]
[s]durchstreichen[/s]
[size=4]skalieren[/size]
[sup]hochsetzen[/sup]
[sub]runtersetzen[/sub]
Umbrechen[Br]Neue Zeile
[center]zentriert[/center]
[left]linksbündig[/left]
[right]rechtsbündig[/right]
[rtl]von rechts einschieben[/rtl]
[pre]Vorformattierung erhalten[/pre]
[move]Bewegen/Laufschrift[/move]
[shadow=red,right]Schattieren[/shadow]
[font=arial]Anderer Zeichensatz[/font]
[glow=yellow,2]„glühen“/markieren[/glow]

Horizontale Linie: [hr]

Abkürzung mit Erklärung bei Mouseover:
[acronym=Mysteriöse Inselzone]MIZ[/acronym]
am besten auch unterstreichen:
[acronym=Mysteriöse Inselzone][u]MIZ[/u][/acronym]

Link innerhalb des Beitrages oder derselben Seite:
Ziel setzen: [anchor=Ziel]Ziel[/anchor]
Link darauf: [iurl=#Ziel]Link zum Ziel[/iurl]

Link im selben Fenster öffnen:
[iurl]http://www.apfelinsel.de[/iurl]

Name:
Betreff:
Verifizierung:
Buchstaben anhören

Gib die Buchstaben aus dem Bild ein:


Zusammenfassung

Autor: MacFlieger
Februar 08, 2012, 11:56:33
Irgendwie komme ich nicht richtig weiter. :(

Solange der Server erreichbar ist, klappt alles perfekt.
Wenn der Server aber mal nicht erreichbar ist, passiert folgendes:
- iPhone mit iOS 5. Man bekommt keinerlei Meldung, dass der Server nicht erreichbar ist. Sobald der aber wieder erreichbar ist, werden die geänderten Daten ohne weitere Meldung auf den Server übertragen. Genauso habe ich es erwartet, d.h. das Gerät cacht zwischen und holt die Synchronisierung nach.
- iCal 4 unter 10.6: Bei einer Änderung kommt die Meldung, dass der Server nicht erreichbar ist mit den zwei Möglichkeiten "Zurück zum Server" (Default, wenn man das wählt, verschwindet der Eintrag auf dem lokalen Rechner) oder "Offline schalten" (man merkt gar keine Konsequenz). Egal, was man wählt, die Änderungen werden auch nicht mehr später auf den Server synchronisiert, wenn der wieder erreichbar ist.
- iCal 5 unter 10.7: Das gleiche Vrehalten wie bei iCal 4 unter 10.6 mit dem kleinen Unterschied, dass der lokale Eintrag auch bei Auswahl von "Zurück zum Server" nicht verschwindet.

Unter iOS funktioniert es genauso wie erwartet und erwünscht. Mit iCal funktioniert es gar nicht, wenn der Server mal nicht erreichbar ist. Jetzt frage ich mich: Ist das normal und bei anderen CalDAV-Servern auch so? Wenn ja, dann kann ich das komplett abschreiben, wenn nein, könnte ich noch einmal versuchen, einen anderen zum Laufen zu kriegen.

Irgendwie macht das alles keinen Spaß. :(
Autor: MacFlieger
Januar 21, 2012, 12:18:11
Danke für die ausführlichen Erklärungen.

Zu CalDAV:
Ja, ich hatte das auch so wie bei IMAP verstanden mit gecachten Daten. Aktuell ergibt sich aus den Tests ein Problem. Wenn ich den CalDAV-Server abschalte, dann auf drei Geräten (iOS 5, iCal SL, iCal Lion) jeweils eine Änderung mache und danach den CalDAV-Server wieder einschalte, spricht sich nur eine der Änderungen auf die anderen Geräte rum. Die Änderungen der zwei anderen Geräte tauchen nirgendwo auf. :(
Das taugt so nix, da auch keine Meldung kommt und man auch gar nicht merkt, dass was nicht verteilt wurde. Das dürfte eigentlich nicht sein, oder? In dem Fall läge es an der verwendeten CalDAV-Software (SabreDAV). Der integrierte CalDAV-Server von Synology taugte auch nix. Man durfte in keinem Eintrag irgendwo ein <, > oder & drin haben, sonst bekam man zwar auch keine Fehlermeldung, aber alle Einträge nach diesem wurden nicht mehr gesynct. Lag dabei daran, dass der CalDAV-Server die Daten ungefiltert in ein XML-Dokument schrieb.  ::)
Vielleicht doch mal DAViCal probieren? Scheint aber deutlich aufwändiger zu sein.

Zu CardDAV:
Das Adressbuch von OS X und iOS cachet nicht zwischen? Dann wäre das für den praktischen Einsatz (Ausland, Funkloch etc.) ja völlig ungeeignet. Mist.  >:(
Im privaten Bereich ist es auch eher so, dass der Kalender größer als das Adressbuch ist. Das wäre nicht das Problem. Auch würde dann jeder Zugriff auf das Adressbuch in einer iOS-App Datenkontigent kosten und langsam sein. Klingt nicht sehr attraktiv.  :(
Autor: mbs
Januar 21, 2012, 10:49:06
Zwar habe ich noch nicht alle Details ausprobiert, aber ich verwende CalDAV und CardDAV testweise in ihrer "Originalimplementation", d.h. auf einem Mac OS X Server.

Du musst Dir die Sache im Prinzip so vorstellen, wie eine Web- oder IMAP-Verbindung: Die Daten kommen in der Regel "live" vom Server. In iCal wird der Serverzugriff zusätzlich gecachet, d.h. wenn die Verbindung zum Server verloren geht, bleibt eine Read-Only-Kopie der Daten auf dem Client erhalten. Der Kalender ist also immer noch einsehbar und Terminerinnerungen finden wie bisher statt. Nur Updates zwischen Client und Server sind währenddessen nicht möglich, egal in welche Richtung. Was die Meldung "Zum Server zurück" bedeutet, kann ich auswendig jetzt auch nicht sagen, aber ich vermute, dass einfach "Kontaktaufnahme nochmal versuchen" gemeint ist. Aus einem hängenden Aktualisierungsvorgang dürfte man nur herauskommen, wenn man entweder die Aktualisierung verwirft oder die Server-Verbindung wieder herstellt.

Das Adressbuch cachet nicht, da es sich in der Regel um sehr viel größere Datenmengen handelt. Wenn der Server offline ist, verschwinden auf dem Client stillschweigend alle serverseitigen Adresseinträge und wenn man wieder im Netz ist, sind sie ebenso stillschweigend wieder da.

In beiden Fällen können die Originalimplementationen der Server optional über Apple-Push-Notifications signalisieren, dass sich der Datenbestand auf dem Server geändert hat.

Zitat
Was soll dieses principals?

In den meisten Fällen sind die Benutzerkonten des Betriebssystems nicht mit den Nutzerparteien eines i...DAV-Dienstes identisch. Wenn ein Benutzer nur sein eigenes Adressbuch und seinen eigenen Kalender auf dem Server ablegt, hätte er nicht viel davon, außer vielleicht einer automatischen Synchronisation seiner persönlichen Mobilgeräte. In den meisten Fällen wird es aber so sein, dass mehrere Benutzer ihre Datenbestände teilen, also gemeinsam über den Server nutzen. Dazu muss man also eine Art virtuellen DAV-Benutzer anlegen und allen Systembenutzern dessen Kennwort mitteilen. Man legt quasi eine kennwortgeschützte Benutzergruppe an, die aber mit den herkömmlichen Gruppen des Betriebssystems nichts zu tun hat.

Um klarzustellen, dass die DAV-Nutzerparteien quer zu den Nutzern und Gruppen des eingesetzten Betriebssystems (oder mehrerer Betriebssysteme) stehen, hat man dafür ein anderes Wort eingeführt, nämlich den "Prinzipal". Ein Prinzipal ist also so etwas wie ein WebDAV-Nutzeraccount. Genaueres kannst Du im WebDAV-Standard RFC 3744 nachlesen. Dort findet man auch die nette Definition:

Zitat
A principal is a network resource that represents a distinct human or computational actor that initiates access to network resources. Users and groups are represented as principals in many implementations; other types of principals are also possible. A URI of any scheme MAY be used to identify a principal resource.

Der URI-Pfad "principals/admin" weist also auf den Datenbestand des Prinzipals "admin" hin.
Autor: MacFlieger
Januar 20, 2012, 18:15:41
Da ich iCloud nicht nutzen möchte, aber immer mehr Geräte mit Kalenderfunktion im Haushalt vorhanden sind die teilweise auch von mehreren gleichzeitig verwendet werden, würde ich gerne für Adressbuch und Kalender etwas ähnliches "nachbasteln". Beide Programme unter OS X und iOS unterstützen dazu ja CalDAV und CardDAV und so müsste man "nur" einen entsprechenden Server bereitstellen. Da bei uns sowieso ein Synology-NAS mitläuft, wäre das dafür ideal.

In der c't war vor kurzem genau dazu ein Bericht zur Benutzung von DAViCal. Leider benötigt DAViCal einen PostgreSQL-Datenbank-Server, der auf unserem NAS nicht so ohne weiteres drauf zu kriegen ist.

Ich habe dann mal ein wenig gesucht und bin auf SabreDAV gestossen. Das benötigt nur sqlite oder MySQL, was beides auf dem NAS vorhanden ist. Die Konfiguration war etwas knifflig und ich habe die auch noch nicht richtig fertig (z.B. noch keine gewünschten User mit eigenen Kennwörtern, noch kein SSL bzw. Zugriff von weltweit), das dürfte aber kein Problem sein. Ich hab erst einmal die Beispieldaten drauf, um zu testen, ob es funktioniert.
Und: Es funktioniert tatsächlich solange der Server erreichbar ist. Ich kann die Daten auf jedem Gerät ändern und auf den anderen ist es nach kurzer Zeit angekommen. Soweit, so gut.

Aber ich teste gerade auch, was passiert, wenn man keine Verbindung zum Server hat (z.B. im Ausland, in einem Funkloch oder bei nicht funktionierendem Internetanschluß zu Hause) oder der Server mal nicht läuft (z.B. weil Stromausfall war, gerade ein Update gemacht wird). Und da bin ich mir nicht so ganz sicher, ob es funktioniert. Ich hatte erwartet, dass iCal bzw. der Kalender melden, dass der Server nicht erreichbar ist und später, wenn er wieder da ist, alles nachholen.
Unter iOS bekommt man überhaupt keine Rückmeldung oder kann sehen, ob der Server erreichbar ist. OK, wäre nicht das Problem.
Unter OS X aber bekommt man bei einem Neueintrag oder Änderung eine Fehlermeldung: "Der Server meldet einen Fehler. "http://xxxxxxxxxx" ist keine gültige URL, die diese Anfrage unterstützt. Soweit zwar etwas komisch formuliert, aber in Ordnung. Zur Auswahl hat man dann "Offline schalten" und "Zum Server zurück" (default). Was mit dem defaultmäßig aktiven "Zum Server zurück" gemeint sein soll, weiß ich nicht. Aber, wenn man das nimmt, verschwindet der gerade geänderte Eintrag ganz. Aber egal, was man geklickt hat, man bekommt die Fehlermeldung (aber nur noch mit OK-Button) dann jede viertel Stunde, wenn die Aktualisierung versucht wird. Das ist nervig.

Weiß jemand, was das mit dem "Zurück zum Server" auf sich hat und wie man diese ständig wiederholenden Meldungen weg kriegt?

Und noch eine Verständnisfrage:
Es wird zum Zugriff eine URI angelegt "principals/admin". Was soll dieses principals?