[Featurewunsch] LBS => CalDAV (bspw. mit Baikal) als Alternative zu Google-Kalender

[MIT]

Hallo zusammen,

nun werfe ich mal eine Idee (und einen persönlichen Wunsch) in den virtuellen Raum, der sich mit der Realisierung eines Bausteins (LBS) zur Umsetzung des CalDAV-Protokolls mit (bspw.) Anbindung an einen Baikal-Server - als (wie ich denke) sehr gute Alternative zum Google-Datenkrakenkalender - beschäftigt.

Die Idee sieht so aus, dass es möglich sein sollte die CalDAV-Kalenderdaten - die bspw. bei einem Hoster oder dem eigenen (Baikal- bspw.) Server gespeichert sind, in die Visu von edomi zu integrieren. Es gibt hier bereits gute LBS, die bspw. als Datenquelle ein Textfile haben (Stichwort Müllkalender). Ggf. könnte man diese Bausteine "umstricken", so dass es möglich ist diese Kalenderdaten - die ja auf dem Server auch wunderbar syncronisiert werden können - in die Visu zu bringen. Wir haben bspw. mehrere Kalender (Familie, Müllkalender, Geburtstage, Geschäftlich etc.), was sich in der Praxis bereits seit einigen Jahren sehr gut bewährt hat.

Ich würde ja selber tätig werden, kann es allerdings momentan aufgrund extremen Zeitmangels nicht; da ich mich erst intensiver mit PHP beschäftigen müsste. Meine bescheidenen Programmierkenntnisse liegen eher im Bereich C / Java / HTML .. - Somit bin ich so "frech" und frage einfach mal so hier in die Runde bzw. wende mich an die vielen versierten PHP-Programmierer hier, ob nicht auch Interesse für meine geschilderte Idee besteht.

Selbstverständlich stehe ich gerne für intensive Tests (so notwendig) zur Verfügung.

Bin auf eure Rückmeldungen gespannt. Wie seht Ihr das? - "Alles Quatsch" oder "Gute Idee" oder "Vielleicht mal irgendwann ... "

DANKE!

VG
Thorsten

EDIT: Die Daten werden vom Server natürlich via https-Protokoll abgerufen.

[wintermute]

Hi,

ich hatte mal mit dem Gedanken gespielt ICS-Dateien (hier von einem Zimbra) zu parsen, allzu kompliziert ist das ja nicht wirklich.
Was mir aber nicht wirklich klar wurde war, wie man solch einen LBS "strukturieren" sollte, also welche Ein- Ausgaenge man braeuchte, welche Daten ueberhaupt relevant sind und wie man die dann visu-technisch verarbeiten koennte. Hast Du da eine konkrete Vorstellung von?

gruesse :: Michael

[MIT]

Hi MIchael,

vorab besten Dank für deine Antwort.
Ich stelle mir vor, dass man das so ähnlich bauen würde, wie beim Thunderbird; sprich was zur Erstellung eines Kalenders angegeben werden muss:

Eingänge:
> Protokoll (ICS / CalDAV)
> URL zum Server
> Kalendername
> Benutzer
> Passwort
> Abrufintervall (ggf. extern durch andere LBS)

Ausgänge:
> Termin
> Beschreibung
> Wiederholung
> Erinnerung
> Anzahl darzustellender/abzurufender Termine => ?

>> Nur mal eine grobe Idee... ob das so sinnvoll ist, weiß ich nicht.
Ggf. kann man sich den String, der vom Server kommt parsen und schauen, was davon verwertbar/sinnvoll ist.

Oder?

EDIT: Ach ja: und Visu-technisch verarbeitet würden die Daten in Form einer Textausgabe (würde mir für den ersten Step auf jeden Fall reichen); die Visu als Read-Only-Medium für diese Daten. Dann muss auch nicht gesyncht werden und wenn Änderungen gewünscht sind, kann man schnell das Handy zücken ... Was meinst Du?
Also bspw ganz trivial:
04.04.2016, 08:00-12:00: Müllabfuhr
10.04.2016, 00:00-23:59: Geburtstag Anja

[MIT]

Die Struktur einer URL, die für den Abruf vom Baikal-Server verwendet wird, sieht bspw. so aus:
https://<DOMAINNAME>/cal.php/calendars/<BENUTZERNAME>/<NAME_DES_KALENDERS>

[wintermute]

Ach ja: und Visu-technisch verarbeitet würden die Daten in Form einer Textausgabe (würde mir für den ersten Step auf jeden Fall reichen); die Visu als Read-Only-Medium für diese Daten.

Ja, das auf jeden Fall!

Ich bin nicht der Kalender-Profi, aber wenn ich unseren Server hier kontaktiere, dann bekomme ich ein ICS-File mit dem Inhalt des kompletten Kalenders zurueck. Das koennte man jetzt parsen (zB nach aktuellem Datum inkl der naechsten 3 Tage, oder nach zB 10 Terminen ab jetzt). Dann haette man also (gemaess Deines Beispiels) 10x4 Ausgaenge (was ich etwas unuebersichtlich finde) - oder man gibt als Eingang mit welches konkrete Ereignis interessiert (zB angefangen bei 1 fuer den ersten kommenden Termin). Dann taete der Baustein immer nur einen Termin auswerfen (was ich persoenlich viel charmanter faende) und man koennte ueber den Eingang quasi hochzaehlen... allerdings wuerde dann entsprechend oft der Server befragt und das File geparsed - was dann auch wieder irgendwie uncharmant ist.

Also File holen, parsen und irgendwas ausgeben ist keine Sache - nur ist mir noch immer keine zuendende Idee bzgl des vollstaendigen Konzeptes gekommen o\

[MIT]

Ja, das auf jeden Fall!

herrlich .. :-)

[...] Dann taete der Baustein immer nur einen Termin auswerfen (was ich persoenlich viel charmanter faende) und man koennte ueber den Eingang quasi hochzaehlen...

Ist doch super! - Warum nicht?

allerdings wuerde dann entsprechend oft der Server befragt und das File geparsed - was dann auch wieder irgendwie uncharmant ist.

Meine Idee soll den kompletten Kalender nicht ersetzen. Ich denke eher daran einen aktuellen Überblick für die nächste Woche (bspw). zu haben. Wenn man einen Termin weiter in der Zukunft sucht, kann man ja auf die App im Handy zurückgreifen. Im Thunderbird ist defaultmäßig 30 Minuten als Aktualisierungsintervall angegeben. Wäre doch vollkommen i.O. und das Server-Polling ist überschaubar. Oder habe ich da was falsch verstanden?

Also File holen, parsen und irgendwas ausgeben ist keine Sache - nur ist mir noch immer keine zuendende Idee bzgl des vollstaendigen Konzeptes gekommen o\

hmmm.... da bin ich vermutlich zu sehr Laie, als ich da behilflich sein könnte.... Aus meiner Sicht wäre File holen, parsen und ausgeben bereits perfekt! ;-)

[wintermute]

hmmm.... da bin ich vermutlich zu sehr Laie, als ich da behilflich sein könnte.... Aus meiner Sicht wäre File holen, parsen und ausgeben bereits perfekt! ;-)

Dann bau ich demnaechst mal eine kleine POC-Version, die koenen wir dann ja als Arbeitsgrundlage nehmen

[Stoxn]

Das Problem ist die Auswertung von Arrays (Stichwort 10x4 Ausgänge). Beim Wetterbaustein von WagoKlemme ist es ja ähnlich: 50(!) Ausgänge für die kommende Woche. Dabei werden "nicht mal" (keine Kritik) alle Infos übergeben, die mit einem Abruf verfügbar wären (z.B. stündliche Vorhersage für den Tag).

Das lässt sich mE auch nicht lösen, aber eventuell macht es Sinn Abruf und Parser zu trennen? Sprich, ein Baustein holt alle Infos und schreibt diese in ein internes KO (Größe?) oder sogar eine Tabelle. Die Aufbereitung läuft separat: Array + Stichwort(e) ("Geburtstag: ", "Müll*", "Feiertag: ", "Urlaub", ...) als Eingang, nächsten zehn Termine als Ausgang. Dann kann sich jeder seine Namenskonvention selbst aussuchen.

Wäre das eine umsetzbare Idee?

[Stoxn]

...oder kann ein LBS ins Meldungs- / Datenarchiv schreiben und anschließend ein Select darauf ausführen?

[wintermute]

Wäre das eine umsetzbare Idee?

Ich hatte mir bis jetzt ueberlegt, dass der Baustein einen Kalender "abholt", aufbereitet und temporaer auf Platte ablegt. Ein Zugriff auf den Baustein haette dann nicht automatisch einen Request zur Folge (es sei denn, eine bestimmte Zeitspanne wurde ueberschritten), sondern greift auf die bereits vorhandenen Daten zu. Man koennte dann nen Kalendernamen (der sich vermutlich aus mehreren Daten zusammensetzen wuerde) und eine Nummer des Termins angeben und der Baustein liefert die entsprechenden Resultate...

[wintermute]

Uhm, zur Klaerung im Vorfeld, weil die Begriffe CalDAV und iCalendar so gerne vermischt werden (von mir hier auch, ist mir naemlich aufgefallen )...

Ich wuerde einen Parser fuer Files im ics Format bauen, keinen CalDAV Klienten (den koennte ich naemlich nicht testen und ausserdem ist mir das zu wirr). Koennen die angesprochenen Loesungen ics Files exportieren?

[jonofe]

Hier gibt es übrigens einen ics Parser, der kompatibel zu PHP 5.3 ist:

https://github.com/johngrogg/ics-parser

Vielleicht ist das ja schon ein Schritt in die richtige Richtung...

[wintermute]

Parser fuer iCal zu schreiben ist nicht die Welt... ich finds immer doof wenn man alles moegliche zu nem LBS dazuinstallieren muss, da mach ich das bissel lieber selber

[saegefisch]

spannend, darüber denke ich auch schon eine Weile nach - aber war mir aktuell noch so wichtig; wollte erst Haus und Visu haben. Kalender fand ich Kür. Wäre auf jeden Fall aber auch interessiert.

Meine Gedanken dazu:

• Wir organisieren uns auch in der Familie komplett über (lesend untereinander freigegebenen) Kalender . Das Ganze bei Apple (angefangen damals, als es noch 120€/a kostete unter "@me.com" lief). Ich gehe davon aus, dass Apple (hoffentlich) nicht an den Daten an sich interessiert ist. Anders als Google.
• Prinzipiell ging es mir daher um WebCal/iCalendar.
• Sollte auch mit OwnCloud und anderen Lösungen (ob eigener Host oder gehostet) funktionieren, die diesem Standard folgen. Das wäre für mich die nächste Stufe, wenn ich Apple nicht mehr vertrauen würde.
• ICS ist aus meiner Sicht "nur" für statische Themen sinnvoll (z.B: Müllkalender, Feiertage, Vereinstermine,...). Oder ich habe ICS noch nicht hinreichend verstanden bzw. deren dynamische Generierung.
• Ich widerrufe den letzten Punkt, wenn man ICS periodisch automatisch erzeugen kann aus eigenen Kalendern.
• An dieser Stelle möchte ich einen sehr wesentlichen Aspekt vermerken: Wie wird ein Termin wieder in der gedachten Lösung gelöscht, wenn er wieder gelöscht wurde? Es braucht daher in jedem Fall ein Delta-Handling. Sonst nützt der Prozess nichts im Familienleben, sondern wirklich nur für Statisches (per Full-Upload)
• Ich sehe ebenso eine lokale Ablage auf dem Edomi-Server.
• Ich sehe ebenso eine Trennung in periodische Bereitstellung (und z.B: Delta-Handling lokale Ablage) und einem oder mehreren LBS für die Nutzung. Mehrere, da man die Daten ggf. auf unterschiedliche Weise nutzen möchte. Damit hätte man eine zentrale Kalender-Ablage ("golden Source") und x Möglichkeiten der Nutzung. Und ein LBS für Mülltermine möchte vielleicht ganz anders arbeiten als für Feiertage oder Geburtstage oder morgige Termine.
• In der Ausgabe wäre das Meldungsarchiv eine Lösung. Ich sehe ebenso keinen Kalenderersatz für mich, sondern nur ein paar anstehende Daten (z.B. Geburtstage, Müll, Hauspflichten, Termine heute und morgen).
• Vielleicht wäre alternativ die Ausgabe in x definierte Visu-Elemente mit Text (wir haben ja 10.000 Zeichen) auch sinnvoll? Wie gesagt: Beliebig viele LBS für die Ausgabe, wenn ein zentrales Kalender-LBS sich um die Abholung und Datenbasis kümmert.

Fazit: Mir wäre es wichtig, nur eine Ablage und nur eine Lösung für alles Kalendarisches zu haben. Schön wäre, wenn der Input aus ICS (Geburstage,Mülltermine,...) und auch WebCal (aktuelle Termine) kommen könnte.

Gerne unterstütze ich bei der Lösungsfindung und auch Entwicklung (auch wenn ich in PHP absoluter Neuling bin)

just my 2 cents
Carsten

[jonofe]

War ja auch nur eine Idee. Ich bin ein Fan davon bestehende Lösungen wiederzuverwenden, vielleicht weil ich von Natur aus faul bin . Der Autor erlaubt es ja explizit, die Klasse in eigene Projekte einzubinden. Könnte man also auch in den LBS einbinden ohne etwas dazu installieren zu müssen.