Anregung fuer 57_Calendar zur Nutzung von ferienwiki.de

[betateilchen]

sch... SVN. Arbeit von 2 Stunden futsch.

[betateilchen]

Hallo Boris, kann es sein, dass das Attribut update = sync|async überhaupt nicht mehr relevant ist?
Im Code habe ich keine Stelle gefunden, an der dies ausgewertet wird.

Wenn dem tatsächlich so ist, schmeiß ich das gleich aus der commandref raus.

[Otto123]

Hallo Udo,

das ist genau mein Eindruck. Und kann es sein, dass update = none zumindest beim Systemstart keine Wirkung hat?
Ich habe einen Kalender eingebunden, der blockiert meinen Pi 1 jeweils (gefühlt) 5 min beim Laden. 
Beim Systemstart und beim Update...
Ich kann das noch genauer untersuchen.

Gruß Otto

[betateilchen]

So langsam gerät dieser Thread komplett durcheinander...

[betateilchen]

Ich nehme meine Frage bezüglich sync/async zurück, ich habe doch eine Stelle gefunden, nämlich beim Verarbeiten des per url geladenen Kalenders.

Code Auswählen Erweitern


    if(AttrVal($name, "update", "sync") eq "async") {
      Calendar_AsynchronousUpdateCalendar($hash);
    } else {
      Calendar_SynchronousUpdateCalendar($hash);
    }


Das Holen des Kalenders von der url erfolgt immer nonblocking.

Das erklärt auch folgendes Phänomen:

Wenn das Attribut update auf "none" gesetzt ist, werden die Kalenderdaten immer synchron (blocking) verarbeitet.  Eine asynchrone Verarbeitung findet nur statt, wenn das Attribut explizit auf "async" gesetzt ist. Das wiederum schließt die Verwendung von "none" aus.

Genau so bin ich nämlich auf diese Frage gestoßen. Wenn ich das Attribut update = onUrlChanged setze, funktioniert das asynchrone Verarbeiten auch nicht mehr.

Man sollte darüber nachdenken, die asynchrone Verarbeitung als Standard zu verwenden anstatt wie bisher die synchrone Variante.

[betateilchen]

Achso, und um diese Frage noch zu beantworten

kann es sein, dass update = none zumindest beim Systemstart keine Wirkung hat

Beim Systemstart wird ein Kalender immer geladen, weil zum Zeitpunkt, zu dem das define ausgeführt wird, das Attribut noch gar nicht bekannt ist.

Das Attribut update gibt laut commandref

The optional parameter interval is the time between subsequent updates in seconds.

den Abstand vor, in dem ein Update des geladenen Kalenders durchgeführt wird. Insofern ist das kein Fehler, sondern genau das Verhalten, das auch beschrieben ist.

[Dr. Boris Neubert]

Hallo,

es wird komplex...

Ich bin heute Abend einige Stunden im Zug unterwegs und gucke mal in den Code. Dann melde ich mich mit validierten Aussagen wieder.

Folgende Dinge aber fallen mir jetzt schon ein:

async|sync und none|onChangeUrl sind zwei unabhängige Aspekte und sollten in zwei Attribute namens synchronousUpdate und update kodiert werden.

Code Auswählen Erweitern

attr myCalendar synchronousUpdate 0|1 (asynchon ist damit der Default).

Code Auswählen Erweitern

attr myCalendar update none|onChangeUrl

Das bricht die Abwärtskompatibilität, macht aber nix kaputt.

Der Kalender sollte kein Update bei der Definition machen und ich dachte, dass erst bei global:INITALIZED ein Update angestoßen würde. Dann sind die Attribute bekannt. Allerdings wird der (ziehmlich fette) Zustand des Kalenders nicht gespeichert, so dass es doch sein kann, dass man den Kalender wenigstens einmal nach dem Start abgeholt haben muss.

Die einzelnen Schritte, die zu den Weckzeiten und Prüfintervallen des Kalenders abgearbeitet werden, müssen vermutlich noch leicht anders geschnitten werden. Zum Glück habe ich das Modul gut dokumentiert.

Viele Grüße
Boris

[nils_]

bevor ihr alles neu macht (es gibt ja nun mehrere threads mit erweiterungen ), bitte bindet doch den übersetzten teil der commandref mit ein.
danke!

[betateilchen]

@nils_ Wenn ich herausfinden könnte, welche der Übersetzungen jetzt die "verbindliche" ist, hätte ich das längst gemacht.

[betateilchen]

async|sync und none|onChangeUrl sind zwei unabhängige Aspekte und sollten in zwei Attribute namens synchronousUpdate und update kodiert werden.
...
Das bricht die Abwärtskompatibilität, macht aber nix kaputt.

Die Idee mit zwei Attributen wäre jetzt mein nächster Schritt gewesen.

Zum Thema Abwärtskompatibilität: sollte ein User tatsächlich das vorhandene Attribut "update" auf sync|async gesetzt haben, kann man in Calendar_Attr() eine entsprechende Meldung ins Log schreiben und das Setzen einfach ignorieren.

Bevor ich aber jetzt weiterbaue, warte ich erstmal ab, was Boris heute noch rausfindet

[nils_]

@nils_ Wenn ich herausfinden könnte, welche der Übersetzungen jetzt die "verbindliche" ist, hätte ich das längst gemacht.

ja verstehe ich.
darum hatte ich ja auch im commdref thread nochmal nachgefragt

das soll euch aber nicht bei der weiterentwicklung bremsen  

[Dr. Boris Neubert]

Logik scheint ganz allein in GetUpdate() reinzumüssen.
none sollte auch beim Start NICHT Update anstoßen, wenn ich mir den Code ansehe.

[betateilchen]

Logik scheint ganz allein in GetUpdate() reinzumüssen.
none sollte auch beim Start NICHT Update anstoßen, wenn ich mir den Code ansehe.

Beim ersten Satz bin ich komplett bei Dir.
Beim zweiten Satz bin ich mir nicht sicher. Davon abgesehen, würde das Laden eines Kalenders beim define für mich immer Sinn machen, unabhängig von einem gesetzten Attribut. Im Sinnes eines konsistenten Datenbestandes halte ich das für entscheidend.

[Dr. Boris Neubert]

ad none: muss ich mir Sonntagabend auf 28" nochmal überlegen...

[betateilchen]

Ok, den Rest habe ich in Arbeit.