Textfeld > 14 Byte

[Chris M.]

1) Abrufen á la RSSlog als JSON oder XML (bzw. RSS)
Pros: sehr einfach zu realisieren (15 Zeiler)
Cons: Dummes Polling, kein Push. evtl. Resoucenintensiv am Server bei häufiger Verwendung

Con: Durch Polling gibt's keine sofortige Rückmeldung, sondern nur dann wenn gerade gepollt wird
Außerdem: dadurch geht es nur mit extra Widgets und nicht mit den bestehenden
=> Würde ich nicht machen wollen

2) Hinzufügen eines weiteren Clients & Transforms zur CV

+

2a) ein Plugin mit einem Mini-Webserver (-> socket; sollte gehen) das json auswirft
2b) ein Plugin als Websocket-Server; ist vermutlich sogar einfacher zu implementieren als 2a) weiss aber nicht ob man darauf jetzt Browserseitig setzen kann??
Pro: Push
Con: erheblich aufwändiger
Aber dafür gleich richtig

In die Richtung würde ich gehen wollen. Mir ist aber die richtige Umsetzung noch nicht ganz klar, da man sich irgendwie in die BDB so reinhängen müsste, dass man bei jedem Commit benachrichtigt wird...
Zum Beurteilen was geht und was nicht, kenne ich BDB (und/oder den wiregated) zu wenig.

3) eibd auf 32-Bit "interne" GA's erweitern, wie bereits schonmal andiskutiert; am Frontend müsste man fast garnichts ändern, am Backend wenig (ist dafür härter und nicht persistent)
Cons: Vergewaltung des eibd
Pros: evtl. Plattform und sogar Systemübergreifender..

Die Idee gibt's ja schon länger, wirklich gut finde ich die nicht. Da wird IMHO der eibd missbraucht. Und was kommt als nächstes? Soll der dann 1wire sprechen? Oder gar die USB-Webcam streamen?

Da bleibe ich lieber bei der Unix-Grundannahme: für jede Aufgabe ein eigenes Tool.

Wie sollen wir da weitermachen? Um die Backend-seite würde ich mich irgendwie kümmern, vor dem erweitern des Transforms, so mit Editor und so hab ich etwas mehr bammel aber es wäre evtl. das sauberere

Die Transforms sind kein Thema (v.a. da ich Plain-Text nehmen würde), die bekommen wir schon hin.

Aus Client-Sicht gibt's ja wohl zwei Möglichkeiten:

• Einbinden im bestehenden "r" und "w" - dann muss einfach der Namespace passen
• Parallele Bereitstellung (d.h. "r" und "w" in einem anderen Verzeichnis oder gar anderem Port)

Erstes sollte vermutlich aus dem Stand gehen (und ist extra für solche Themen eingbaut), bei letzterem müsste bisschen was auf Client-Seite gemacht werden, wäre aber wohl überschaubar.

[makki]

=> Würde ich nicht machen wollen

Ok, wäre auch nur ein Notnagel, ist halt erstmal erheblich übersichtlicher; ich pinsel da einfach mal ein CGI das analog mit filter einen RSS-Feed ausgibt bzw. hab ich das schon gemacht aber dabei ist mir aufgefallen das es nicht das gelbe vom Ei ist

In die Richtung würde ich gehen wollen. Mir ist aber die richtige Umsetzung noch nicht ganz klar, da man sich irgendwie in die BDB so reinhängen müsste, dass man bei jedem Commit benachrichtigt wird...

Eher nicht, es macht ja keinen Sinn jedes Feld an die CV zu senden; "reinhängen" ist da ausserdem so nicht aber dazu hätte ich mir eben was ausgedacht: entweder eine Art visu_notify oder subscribe oder so im Plugin.
Da wäre der Websocket das einfachste: syswrite($websocket,"meinwert:value");
Im Webserver liefe nur ein nennen wir es mal "socket-relay"

[*]Einbinden im bestehenden "r" und "w" - dann muss einfach der Namespace passen

Das ist aber dann dieselbe Vergewaltigung wie 3) Gefällt mir nicht, weil die tun für sich exakt was sie sollen..

[*]Parallele Bereitstellung (d.h. "r" und "w" in einem anderen Verzeichnis oder gar anderem Port)

Jow, und zwar irgendwie letztlich direkt im wiregated, via webserver natürlich, möglich aber nicht ganz trivial..

So 100% zuende gedacht ist es noch nicht aber sowas in der Art-> ist auch stark davon abhängig was man mit welchem Aufwand realistisch hinbekommt

Makki

P.S.: solange verzweifle ich mal weiter an variant & editor.. irgendwas blicke ich da noch nicht..

[Chris M.]

Eher nicht, es macht ja keinen Sinn jedes Feld an die CV zu senden; "reinhängen" ist da ausserdem so nicht aber dazu hätte ich mir eben was ausgedacht: entweder eine Art visu_notify oder subscribe oder so im Plugin.

Ne, nicht jedes Feld - die CV sagt ja genau welche Werte interessant sind...

Habe gerade man in die Perl-Doku geschaut. Und was ich mir nun gut vorstellen kann:
Wir machen eine eigene Tie Klasse, bzw. leiten von dem BDB Tie ab, so dass bei jedem STORE (-> tie - perldoc.perl.org) einfach geprüft wird, ob dieser Key von der CV aboniert ist und entsprechend auf's "r" antwortet. Danach geht's normal mit dem BDB-Tie weiter.

[makki]

Wir machen eine eigene Tie Klasse, bzw. leiten von dem BDB Tie ab, so dass bei jedem STORE

Genau das hab ich gestern und heute durchprobiert Das wär auch so eine der Möglichkeiten aber ich wollte es ehrlichgesagt einfacher und ganz anders machen (ich muss da ja eh ran), ohne kranke Konstruktionen die keiner versteht, ohne tie und Klassen, SUPER_vererben und so, ich mag sowas nicht und der Anwender soll es verstehen; 10% die es wirklich verstehen enttäusche ich dabei natürlich, die können sich das aber auch selber anders coden, 90% sind eher froh nicht wissen zu müssen was eine Klasse ist

(ich hab da schon genug Altlasten, ich müsste irre sein, mir da noch eine vollständig gehirnamputierte reinkarnation eines tied-hash draufzulegen die gefühlt Faktor 100 an RAM der Nutzdaten fordert..)

Kommt erschwerend hinzu, das ganze DBI/Tie::* ist IMHO im Detail stark fehlerhaft (wie übrigens so viele cpan-Module wenn man mal den Perl-Source gelesen hat, versteht man das auch, die pm's können nichtmal was für), das taugt um alle 5 Minuten aus der crontab gerufen zu werden, ist 0 Threadsafe (siehe segfault .. in DB_File.so) -> Bug bekannt seit zig Jahren, resolution: wontfix.
Ich hab mir bei sowas seitdem gemerkt: sowas lieber selber machen, mit dem was man selbst beherrscht.

-> Aber wiegesagt, darum würde ich mich kümmern, irgendwie.

Was mir Angst macht ist ein neues Transform, Editor (ich brauch schon 4h um eine hässlichkeit mit dem Variant zu finden, 3 Zeilen, in der Zeit schreibe ich einen Webserver in Perl, C, oder .. ist halt nicht meins..)
Aber eine CV ohne Editor ist halt auch nur die halbe wahrheit.
Daher die Frage; ich suche den Weg des geringsten Widerstands, der zum Ziel führt, 32bit GA's im eibd reinzunudeln schaffe ich eher als ein zweites transform im Editor.. Das ist nicht die sauberste Lösung aber eine eben machbare, die technisch bessere Alternative wird auch genommen
Konkrete Fragen: wo muss man bei dem neuen Transform überall ansetzen, ich scheiterte heute schon daran, die Variablen eines Widgets von .create in .update zu lesen.. (Soviel zum Thema Perl ist verquer: ja, aber da gibts aber wenigstens Data : : Dumper das mir nicht nur irgendwelche wirren Objekt-prototypen anzeigt )

Makki

P.S.: a propos altlasten der Json-output im rrdtool ist übrigens seit gestern wenigstens in 1.4 upstream

[perf]

Gibt es eine gute Lösung, um z.B. Song-Titles von einem WG-Plugin im Visu anzuzeigen?

/Per

[makki]

So richtig "gut" ohne den "vermeintlichen" Umweg über KNX so noch nicht, meinereiner blendet sich solange relaxx (MPD-Frontend) als iframe ein - geht wunerbar

Makki

[perf]

D.h. ohne die Information durch ein WG-Plugin zu bringen?

/Per

[Chris M.]

Nein, in der aktuellen Lösung müssen diese Daten durch den KNX durch, und der limitiert auf 14 Byte.

Evtl. geht auch was mit erweiterten KNX Frames, da müsste sich aber erst noch jemand drum kümmern.

Die CometVisu an sich kann jedoch auch mit mehr umgehen - aber noch spricht das Backend halt exklusiv mit dem eibd.

[perf]

Vielleicht muss das nicht unbedingt durch das Backend? Der Upnpcontroller-widget macht eigentlich was ich will, aber ich wollte die funktionalität mit WG-Plugins integrieren, um ein bisschen Logik und weitere KNX-integration zu machen, und ich wollte ein bisschen mehr Kontrolle über das Layout.

D.h. ich glaube das beste wäre vielleicht ein einfaches Text-Widget, das aus einem xml oder rss liest, und eine möglichkeit von WG-Plugins aus Information zu publizieren in einem xml och rss. Oder in eine mini-Webpage. (Dann ist das Text-Widget ein iframe.)

/Per

[JNK]

Rsslog

[Chris M.]

Richtig, wenn die Features (inkl. Einschränkungen) davon passen, dann ist das die Wahl.

Es ist aber halt leider kein "first class citicen", d.h. es ist nicht 100% austauschbar mit Strings über KNX. Das würde eben erweiterte KNX Pakete oder ein intelligenteres Backend benötigen.

[perf]

Ich bin nicht ganz überzeugt. Ich will für vier Sonos-player Song-Title, Artist, Album, Volume und Zeit zeigen, in ein vernünftiges und kompaktes Layout. Volume passt als KNX-GA, die anderen eher nicht. Im moment glaube ich an ein Iframe.

/Per

[makki]

Nun, derzeit gibts dafür keinen Masterplan und keine tolle Lösung (RSSLog ist dafür nicht gedacht; andere Ideen erfordern auch "dummes" Polling)

Aber Ideen gäbe es; die Socket-Infrastruktur in den Plugins gäbe das evtl. her, evtl. sogar extended-Frames im eibd da verliessen wir aber den KNX-Standard..
Wie beurteilen wir stand heute das Thema Websockets? Da liesse sich mit vertretbarem Aufwand glaube ich was machen, wenn die Browser mitspielen..

Makki

[perf]

Eine naheliegende Funktionalität, die vielleicht in diesem Zusammenhang bedacht werden sollte, ist, dass man manchmal auch Text(oder Zahl)-Eingabe im Visu haben möchte - z.B. um einer Szene einen Namen zu vergeben.

/Per

[makki]

Wir gleiten zwar etwas OT aber ich denke schon auch durchaus an sowas und vieles andere:
eine Möglichkeit mit "Push" ohne overhead direkt mit der Visu zu sprechen.

Wiegesagt: 1-2 Ideen dazu hätte ich im Kopf, die erste Frage dazu wäre, ob man hier&jetzt auf Websockets setzen kann und sollte? Oder doch eher JSONP. Das (erstere) sieht mir als die eleganteste Lösung aus, im Plugin lässt sich sowas locker schaffen..
(und dann stellen sich dutzende Fragen nach AAA etc. aber das wäre auch schon im Kopf )

Hab da bei den vielen Ankündigungen und zwischenzeitlichen abschaltungen bzgl. Websockets aber den Überblick verloren, was jetzt grad das richtigere ist..

Makki

Edit: die zweite Idee ist nämlich vom Webserver einen Socket aufs Plugin zu biegen, ist nur nicht so ganz transparent und erklärbar..