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

[wintermute]

Jups. Mehrere Kalender, die aber durch ihre URL eindeutig zuzuordnen sind; bzw. unterschiedem werden können, oder?

Vermutlich vornehmlich durch den KalenderNamen. Jedenfalls holt der Baustein nur einen Kalender, auch wenn zB in der WebGUI des Servers alle Kalender zugleich angezeigt werden - das kann zu Verwirrung fuehren
Ich habe es hier mit 2 verschiedenen Kalendern getestet (jeweils mit ICS & CalDAV), da war die Sortierung jedesmal korrekt, sprich: ich habe auch tatsaechlich die naechsten 3 Termine aus dem betreffenden Kalender angezeigt bekommen.

Man kann aufm Edomi Server im /tmp Verzeichnis nachschauen, da liegen die "aufbereiteten" Daten wie sie vom Server gekommen sind; da koennte man evtl sehen ob irgendwelche Termine nicht vorhanden sind (die eigentlich vorhanden sein sollten).

[wintermute]

Apple-Kalender

Danke, pflege ich ebenfalls ein!

[wintermute]

Was ist Dein aktueller Plan dazu?

Ich hab keinen

Technisch: alle zukuenftigen (die anderen sind IMHO uninteressant) Termine liegen jetzt (nach Startdatum sortiert) in einem assoziativen Array und lassen sich per Nummer da rausfischen (also quasi $event[0] fuer den naechsten und $event[2] feur den ueber-ueber-naechsten). Aber wie man die jetzt am sinnvollsten in welchem Format an die Ausgaenge bringt? Ich hab absolut keinen Plan... das war ja auch der Grund wieso ich seinerzeit die Idee des LBS verworfen hatte

[MIT]

In der Datei befinden sich etliche uralt-Termine; Termine, die > 05.04.2016 sind, nur die drei o.g. - alle anderen fehlen.

[saegefisch]

Ich hab keinen )

Habe jetzt 2 verschiedene Kalender mit je allen drei Ausgängen angebunden. Funktioniert! Allerdings sind die Einträge nicht (über die Kalender) kalendarisch sortiert.

Werde mal in den LBS rein schauen und mal darüber nachdenken, was mir den Daten wie sinnvoll erscheint. Ist ja alles perfekt vorbereitet von Dir. Wenn ich eine Meinung habe, melde ich mich wieder. Muss jetzt erst mal damit herum spielen...

[Simone]

Bei mir gehts auch, aber nur mit Tipp von saegefisch weil Link vom öffentlichen Kalender im icloud Popup hieß so

webcal://p<ID>-calendars.icloud.com/published/<?>/<Kalender-GUID>

[saegefisch]

Ein kleiner Schritt für die Menschheit, ein großer Schritt für Edomi...

[wintermute]

Also, zusammenfassend:
-das mit den alten Events in dem /tmp Files: ist natuerlich Bloedsinn was ich geschrieben habe, da sind auch die alten Events drin.
-wieso bei MIT Events fehlen kann ich mir nicht erklaeren, ich kann das leider hier nicht nachvollziehen
-Baustein- bzw Kalender-Uebergreifendes Sortieren... hmm... macht Sinn, aber ist nicht trivial. Evtl mit nem "speziellen" Ausgabeformat und einem Baustein dahinter... dazu muesste aber generell erstmal klaeren in welcher Form und welchem Umfang man die Events ueberhaupt ausgeben koennte.

[MIT]

Bei einem zweiten Kalender (wie gesagt: gleicher CalDAV-Server) funzt es (fast) sauber; d.h. Termine, die als Serie in der Vergangenheit angelegt wurden, werden nicht als anstehende Termine erkannt; ansonsten passt es. Beim erneuten aktivieren des Projektes hatte der erste Kalender wieder andere Termine; aber nicht die nächsten drei.

EDIT: Und auch Termine, die über mehr als einen Tag gehen, werden ignoriert.

[saegefisch]

ich finde: Der wesentliche Teil ist mit der Abholung erreicht. Vielen, vielen Dank dafür! Wir sollten vielleicht alle mal damit herum spielen und in eine Visu einbauen. Und so eine Meinung entwickeln, wie die Daten am besten aufbereitet werden sollten. Dann treffen wir uns demnächst, morgen oder wann auch immer jemand eine Idee hat, hier auf diesem Kanal wieder. Und wer will kann ja bereits selber Hand anlegen und bei Erfolg Code bereit stellen als Vorschlag. Vermutlich gibt es ja auch eine ganze Reihe unterschiedlicher Ideen. Sacken lassen ist manchmal sehr hilfreich.

just my 2 cents

[wintermute]

Termine, die als Serie in der Vergangenheit angelegt wurden, werden nicht als anstehende Termine erkannt; ansonsten passt es.

Strange... bei mir sieht das (im tmp-File) zB so aus:

BEGIN:VEVENT
UID:FF4DA27866A74FA08CD9D74F9CCF404700000000000000000000000000000000
RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTHDAY=8;BYMONTH=8
SUMMARY:Sack Geburtstag
X-CLIENT-UID:RkY0REEyNzg2NkE3NEZBMDhDRDlENzRGOUNDRjQwNDcwMDAwMDAwMDAwMDAwMDA
 wMDAwMDAwMDAwMDAwMDAwMA==
ORGANIZER;CN=blah:mailto:blubb
DTSTART;VALUE=DATE:20130808
DTEND;VALUE=DATE:20130809
STATUS:CONFIRMED
CLASS:PUBLIC
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
TRANSP:OPAQUE
LAST-MODIFIED:20130808T122953Z
DTSTAMP:20130808T122953Z
SEQUENCE:0
END:VEVENT

Jaehrlich wiederkehrend, der LBS macht daraus (korrekterweise) also mehrere Termine - was in erster Instanz meine geplante Array-Struktur hat platzen lassen, weil zB der Termin in 2017 den aus 2016 ueberschrieben hatte und der 2016er damit verloren ging (weil sich die uid dabei nicht aendert).... Angelegt wurde das (wie man oben sehen kann) 2013 - funktioniert hier sauber. Wie sieht denn ein entsprechender Eintrag bei dir im tmp-File aus?

Beim erneuten aktivieren des Projektes hatte der erste Kalender wieder andere Termine; aber nicht die nächsten drei.

Die tmp-Files ueberleben eine Projekt-Aktivierung, die kann man aber manuell (im laufen Betrieb) loeschen wenn man damit rumspielen will...

Jedenfalls ist das entweder ein Bug in der von mir verwendeten "Drittanbieter-Klasse" oder in Deinem Server. In beiden Faellen kann ich da leider nicht allzuviel dran aendern

[wintermute]

just my 2 cents

Guter Plan

[MIT]

Also, bei Events, die vorhanden sind, sieht das bspw. so aus:

BEGIN:VCALENDAR
PRODID:-//Ben Fortuna//iCal4j 1.0//EN
VERSION:2.0
CALSCALE:GREGORIAN
BEGIN:VEVENT
DTSTAMP:20160124T100545Z
DTSTART;VALUE=DATE:20140414
DURATION:P1D
RRULE:FREQ=YEARLY
SUMMARY:Geburtstag ...
DESCRIPTION: ...
CLASS:PUBLIC
STATUS:TENTATIVE
UID:3870b32d-6e86-4b5b-affe-846e5fb233db-caldavsyncadapter
END:VEVENT
END:VCALENDAR

Ein Geburtstag, der jetzt am 22.04.2016 stattfindet, ist bspw. nicht in der Datei. Wie kann das sein?

EDIT: Er ist DOCH da ... tze ... ich glaub ich brauch erstmal ne Auszeit. Dir - Michael - auf jeden Fall herzlichen Dank! Bin optimistisch, dass ich mit meinen Daten auch noch klar komme. Vermutlich bin ich jetzt einfach schon zu müde ... Gute Nacht an alle!

[wintermute]

Wiederkehrende Termine werden mit dem ersten Auftauchen abgelegt und dann gemaess der Wiederholung im Baustein vervielfaeltigt. In den "Rohdaten" sind die nicht vorhanden.

Was ich mir jetzt noch vorstellen koennte, besonders weil Du schreibst es tauchen immer unterschiedliche Termine auf:
Ich bin ja urspruenglich mit ICS gestartet und da stehen alle Termine in einem File. Davon ausgehend hab ich mir gedacht, ich nehme jetzt bei CalDAV auch alle Termine und schraenke das nicht auf einen bestimmten Zeitraum ein - so haette ich in beiden Faellen dieselbe Arbeitsgrundlage. Vielleicht schraenkt dein Server einfach die Datenmenge ein wenn es ihm zuviel wird... wie viele Termine hast Du denn da grob drin (wobei wiederholende Welche nur einmalig zaehlen wuerden)?

[saegefisch]

Nach ein paar Tests ein paar Gedanken:

• Nur als Info: so ein ICS hat mal locker 100KB...und davon entsprechend viele; bei uns wird sich das in der Familie auf zur Zeit rund 600KB summieren. Sollte aber wohl kein Problem sein, solange man die Totzeit nicht zu kurz wählt. Mir wäre keine Funktion bekannt, Serverseitieg die ICS-Erzeugung zu filtern. Bei Bedarf könnte man das nach dem Abholen und vor der lokalen Ablage tun. Aber Platz dürfte nicht unser Thema sein...
• Technisch bedingt sind kalenderübergreifend die Einträge nicht zeitlich sortiert, sondern "nur" je Kalender. Wenn es eine Sortierung nicht im Visu-Element gibt, wäre dies m.E. eine wichtige Funktion. Unterschiedliche Lösungen sind da denkbar: Vielleicht doch LBS-Trennung von Abholen (je Kalender) in zentrale Datenablage und LBS (kalenderübgreifend) eine Ausgabe in ein Archiv? Oder der LBS kann z.B. bis zu 4 Kalender lesen und so eine übergreifende Sortierung hinbekommen. 4 dürfte für viele Anforderungen reichen, aber es bleibt nicht die beste Lösung. Oder zentrale Ablage über mehrere LBS in DB oder File. Wenn man je LBS die zentrale Speicherinstanz auswählen könnte, wäre eine beliebige Kombination von x Kalendern in y Archiven möglich.
• Sollte es irgendwann ein Visu-Element geben, dass eine Sortierung zum Ausgabezeitpunkt (und vielleicht sogar dynamische Filterung?) ermöglichen würde, wäre die bestehende Lösung diesbezüglich bereits wunderbar. Solche Wünsche dürften allerdings mit der gnadenlos guten Performance von Edomi kollidieren; die wollen wir ja nicht gefährden... Dann doch lieber eine PHP-Lösung mit einer zusätzlichen LBS-Funktion zum Schreiben in ein Archiv (siehe auch unten)?
• Eine zeitliche Eingrenzung ist wünschenswert; am besten als Intervall, nicht Einzelwert. So könnte man sich Termine auf "Heute" oder "Heute und Morgen" einschränken. Wäre mir sogar wichtiger als eine übergreifenden Sortierung.
• Die Verwendung des Archivs finde ich eigentlich ganz charmant in der Darstellung und Integration in eine Visu. Wenn man noch je Kalender eine Farbe festlegen könnte...<träum>. Da gäbe es noch Potential, aber auch keine Eile.
• Die für Testzwecke gewählte Einschränkung auf drei Werte ist hinderlich für eine produktiven Einsatz, habe aber gerade auch keine Idee, wie man das dynamisch lösen könnte - solange es keinen grundlegende LBS-Funktion in Edomi gibt, um im PHP direkt einen Eintrag in ein Archiv zu schreiben.
• Eine Ausgabe als Text (<10.000 Zeichen) ist m.E. nur sinnvoll möglich, wenn man darin auch inline formatieren könnte. Ohne ist es ein recht unleserlich; für mich wär's kein Ersatz für ein Archiv.
• Ganz cool wäre, wenn man dem LBS per Maske mit Platzhaltern (am Eingang) die Ausgabe selber formatieren könnte (vielleicht will mal jemand nur das Startdatum. Oder gar kein Datum oder den Kalendernamen voranstellen oder "BDAY" oder was auch immer...). Meine Kunden freuen sich immer über diese Option (wenn kurz nach Rollout Änderungen nötig werden). Könnte so aussehen, z.B. "Müll: <startd> | <summarum> raus stellen!"

Genug Wunschkonzert! Ich find's bereits jetzt sehr hilfreich; vielleicht hat jemand ähnliche Ansichten oder ganz andere oder weitere...ich bin gespannt. Und vielleicht wird sich das ein oder andere sogar gelegentlich umsetzen lassen.

Ich muss dringend mal an kürzeren Beiträgen arbeiten...

@Christian: Gibt es konzeptionelle Hindernisse, direkt aus einem LBS heraus per Funktion ein Archiveintrag zu schreiben?
@Michael: Schönes Coding...schön zu lesen; PHP entwickelst Du beneidenswert effizient. Das hätte ich nicht annähernd so bauen können.