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

[MIT]

[...]... wie viele Termine hast Du denn da grob drin (wobei wiederholende Welche nur einmalig zaehlen wuerden)?

Es sind 770 Events in 5 Kalendern.

[MIT]

@saegefisch: Ich finde deine Ideen gut und mit Sicherheit einen Weg, den man analysieren sollte. Für mich persönlich wäre allerdings die Einschränkung auf vier Kalender unschön. Ggf. könnte ich - aktuell thematisch getrennte - Kalender zusammenführen; das allerdings führt zu einer Einschränkung in der Bedienung an anderer Stellen (bspw. im Tunderbird Lightning). Und da komme ich zu einem weiteren Nice-2-Have-Punkt: Das aktivieren/deaktivieren der einzelnen Kalender in der Ausgabe bzw. - besser gesagt - in der Ansicht.

[wintermute]

[*]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...

Nein, ich denke auch dass man sich wegen ein paar MB Platz keinen Kopp machen sollte - vielleicht wegen der Dauer des Parsens... aber wenn die Kalender numa so gross sind, ja, dann sind sie halt so gross

[*]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.

Geht natuerlich alles, klar... aber ich wuerde lieber erstmal einen Konsens finden was das Bereitstellen der Daten angeht, also wie die Ausgaenge aussehen koennten. Davon ab waere es vllt auch sinnvoll zunaechst mal abzuklaeren, was genau von diesen Beduerfnissen vllt schon Server-Seitig abgebildet werden kann.

[*]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.

Bau ich mit ein...

[*]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.

Das ist klar, das ist ja auch explizit *nicht* fuer den produktiven Einsatz gedacht An der Front sollte man zuerst starten, finde ich...

[*]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!"

Coole Idee, aber wird schwierig, bei zB Zeitformatierungen... ich denk das mal an, aber prinzipiell faende ich es besser wenn solche Dinge durch andere Bausteine erledigt werden und hier nur "Rohdaten" rausfallen wuerden.

@Michael: Schönes Coding...schön zu lesen; PHP entwickelst Du beneidenswert effizient. Das hätte ich nicht annähernd so bauen können.

Danke, aber das ist wirklich keine Raketentechnik. Der Grossteil des Bausteins besteht ja ohnehin aus Fremdcode

[wintermute]

Es sind 770 Events in 5 Kalendern.

Was ja nicht wirklich viel ist o\
Kannst Du vllt mal einen Testkalender anlegen und damit - naja - testen?
Wenn Du da zB 10 Termine reinschreibst, kann man leicht feststellen ob immer die naechsten 3 angezeigt werden oder nicht.

[coliflower]

Hallo zusammen,

zum Thema iCloud/Apple ... falls noch nicht bekoannt - vielleicht ist der nachfolgende Link hilfreich für eurer Unterfangen ?
http://stackoverflow.com/questions/2...ing-php-caldav

[MIT]

Der Test mit dem Testkalender war erfolgreich. Ich habe ca 15 Termine eingetragen (auch Serien) und es wurden nur die nächsten drei ausgegeben. Wenn ich nun weitere Tests machen möchte (bspw. Termine verschieben) - wie kann ich ihn dazu zwingen die Daten vom Server zu holen? - Tempfiles löschen und Projekt aktivieren hat nichts gebracht.

EDIT: Auch einige Variationen bei den Terminen waren im Testkalender nun immer richtig.
In dem Zusammenhang kommt mir die Idee, ob es ggf. sinnvoll ist alle Kalenderdaten zusammen zu kopieren um sie als Quelle für die Sortierung der anstehenden / auszugebenden Termine zu nutzen. Macht das Sinn?

[wintermute]

wie kann ich ihn dazu zwingen die Daten vom Server zu holen? - Tempfiles löschen und Projekt aktivieren hat nichts gebracht.

Entweder ueber die Totzeit (durch entsprechendes Abwarten) oder durch das Loeschen des lokalen Caches. Der lokale Cache liegt zB in /tmp/EDOMI_LBS19000158.202.ics (wobei die 202 jeweils durch die ID des betreffenden LBS zu ersetzen waere). Der Baustein schaut nach ob das File vorhanden ist, falls nicht (oder falls zu alt) wird es neu gefetched. Das Datum der letzten "Abholung" kannste mit nem "ls" rausfinden:

[root@edomi ~]# ls -lda /tmp/EDOMI_LBS19000158.20*
-rw-r--r-- 1 root root 146000  6. Apr 13:34 /tmp/EDOMI_LBS19000158.202.ics
-rw-r--r-- 1 root root   1759  6. Apr 13:34 /tmp/EDOMI_LBS19000158.203.ics

EDIT: Auch einige Variationen bei den Terminen waren im Testkalender nun immer richtig.

Vermutlich liegt es wirklich an der Anzahl der Events im Kalender o\

In dem Zusammenhang kommt mir die Idee, ob es ggf. sinnvoll ist alle Kalenderdaten zusammen zu kopieren um sie als Quelle für die Sortierung der anstehenden / auszugebenden Termine zu nutzen. Macht das Sinn?

Prinzipiell schon, allerdings muesste man dann vermerken aus welchem Kalender welcher Eintrag kommt (damit er beim Fetchen geloescht und neu gesetzt werden kann), das wird bei grossen Kalendern schnell unhandlich (speicher/performancetechnisch betrachtet). Dann waere eine lokale Datenbank schon wieder sinnvoller...

[MIT]

Moin Michael,

Da liegst Du richtig: Das ist ein Serientermin (Geburtstag) ... es wäre diesbezgl. sehr makaber einen Endtermin anzugeben ... ;-)

bist Du da ggf. schon weiter? Oder muss ich meine Freunde und Bekannten diesbezüglich zeitlich terminieren .. was natürlich sehr schade wäre. Und wenn ich das durchschnittlich ereichbare Alter in Deutschland dafür ansetze, könnte ich dem einen oder anderen (hoffentlich!) trotzdem nicht gerecht werden ...
==> ... also nur, damit kein Error-Logeintrag mehr kommt ...

DANKE!

[wintermute]

bist Du da ggf. schon weiter?

Grad nochmal nachgeschaut, es ist das prinzipielle Problem wenn man nicht alles selber macht
Das ist ein Bug in der iCal Klasse, laut icalender-RFC ist DTEND optional, die Klasse geht aber fest davon aus, dass DTEND bei jedem Event vorhanden ist und rechnet damit sogar intern. Mein Zimbra gibt uebrigens - wie es aussieht - immer ein DTEND mit, aber gemaess Definition ist es nicht erforderlich (https://tools.ietf.org/html/rfc5545)...

Der beste Weg zur Heilung waere wohl, das beim Autor als Bug zu melden, also hier:
https://github.com/johngrogg/ics-parser

[MIT]

Grad nochmal nachgeschaut, es ist das prinzipielle Problem wenn man nicht alles selber macht [...]

>> Du bist beruflich (Projekt-)Manager, oder? ...

[...]
Der beste Weg zur Heilung waere wohl, das beim Autor als Bug zu melden, also hier:
https://github.com/johngrogg/ics-parser

>> würdest Du das machen? - Ich denke, Du könntest das am besten erklären ...

[wintermute]

>> würdest Du das machen? - Ich denke, Du könntest das am besten erklären ...

Nein, definitiv nicht...
Ich hab schon genug mit eigenen Projekten zu tun, da muss ich nicht auch noch Fremdsoftware debuggen, betreuen, verbessern & testen

Wie schonmal geschrieben habe ich prinzipiell Probleme damit, Fremdcode einzubinden - wie man hier schoen sehen kann fuehrt das dann naemlich dazu, dass man fuer seine eigenen Projekte nicht mal mehr grundlegende Support bieten kann und stattdessen nur schulterzuckend sagen kann "weiss ich auch nicht, geht halt nicht".
Daher mal die Frage in die Runde: moechte jemand die "Weiterentwicklung" (sofern man das ueberhaupt so nennen kann, der LBS kann ja eigentlich noch garnix) von dem Baustein uebernehmen? Dann wuerde ich ihn im Downportal bei mir wieder rausnehmen - die "fremden Klassen" passen nicht in mein Konzept

[MIT]

Okay! Dafür hab ich vollstes Verständnis !
Was die Meldungen im Error-Log angeht ... da kann ich ja wirklich manuell eingreifen und jedem meiner Kontakte 100 Lebensjahre gönnen ... :-) Dann ist das "Problem" ja quasi vom Tisch. Wie sind denn die nächsten Überlegungen in diesem Projekt (wenn wir diese Sache mal außen vor lassen)? Hattest Du in diesem Zusammenhang mit deinem LBS, der die KOs zusammenführt, getestet? Oder wäre das nicht sinnvoll?

[wintermute]

Was die Meldungen im Error-Log angeht ... da kann ich ja wirklich manuell eingreifen und jedem meiner Kontakte 100 Lebensjahre gönnen ... :-)

"Kann man schon so machen..."
Denn trotzdem ist die Klasse fehlerhaft (weil ja ein nach RFC gueltiges File zu Fehlern fuehrt). Und wer eine RFC umsetzt ohne (scheinbar) die RFC gelesen zu haben, der hat vermutlich auch noch woanders Bugs verbaut...

Wie sind denn die nächsten Überlegungen in diesem Projekt (wenn wir diese Sache mal außen vor lassen)? Hattest Du in diesem Zusammenhang mit deinem LBS, der die KOs zusammenführt, getestet? Oder wäre das nicht sinnvoll?

Ich habe noch garnix weiter getestet, nur die exemplarischen Konfigurationen in die Hilfe eingefuegt... IMHO ist die generelle Frage erstmal, wie (und auch welche) Daten vom Baustein rausgeworfen werden. Dann haette ich einen Abfragezeitraum als Eingang zugefuegt (also zB "2 Monate", gerechnet ab "jetzt") hinzugefuegt und die Events darauf eingegrenzt (bei ICS) bzw die Anfrage entsprechend eingeschraenkt (bei CalDAV).
Ich haette vielleicht noch einen Eingang zugefuegt der angibt welcher Event ausgegeben werden soll und dann an die Ausgaenge die Properties des Events gelegt. Dann koennte man einfach hochzaehlen und bekommt soviele Termine wie man grad braucht.

Ich lad gleich noch mal die aktuelle Version vom Baustein ins Portal....

[MIT]

[...]
Ich haette vielleicht noch einen Eingang zugefuegt der angibt welcher Event ausgegeben werden soll und dann an die Ausgaenge die Properties des Events gelegt
[...]

Bedeutet das so eine Art statische oder dynamische (KO-gesteuerte) Suche ?

Ich lad gleich noch mal die aktuelle Version vom Baustein ins Portal....

Danke! :-)

[wintermute]

Bedeutet das so eine Art statische oder dynamische (KO-gesteuerte) Suche ?

Keine Suche, eher etwas um Listen zu bauen...
Allerdings habe ich ja noch immer keine Visu und daher weiss ich nicht ob das ueberhaupt sinnvoll waere. Ich bin mir nur verhaeltnismaessig sicher, dass 92 Ausgaenge an einem LBS nicht zielfuehrend sind
Nen weiteren Baustein brauchts dafuer jedenfalls nicht, der taete ja nix anderes machen was der jetzige auch schon kann, waere also nur eine Erweiterung des bestehenden Welchen.