Alternatives Protokoll zum Übermitteln und Darstellen von Daten in der CV

[stromie]

Hi zusammen

was ist eigentlich GrAF und wo findet man dazu Infos.

Grüße Stromie

[netsrac]

Alternatives Protokoll zum Übermitteln und Darstellen von Daten in der CV

Bei nochmaligen überlegen komme ich immer wieder auf die Idee zurück bei der address einen zusätzlichen Parameter wie "backend" einzuführen, mit denen man ein anderes backend für diese Adresse definieren kann.

So muß ein Backend nicht immer alle Protokolle sprechen können. Ich denke, dass das für zukünftige Implementierungen fast unumgänglich ist. Habe mal ganz kurz in GrAF geschaut und das erscheint mir auf den ersten Blick ein bischen mit Kanonen auf Spatzen zu schießen :-)

Gruß, netsrac

[Chris M.]

was ist eigentlich GrAF und wo findet man dazu Infos.

Vgl. GrAF - Open Automation:

GrAF steht für "Graphic Automation Framework" und stellt eine LogicEngine so wie dazugehörige grafische Programmiersprache dar.

Infos gibt's unter o.g. Link (das wurde allerdings vor der Implementierung geschrieben, d.h. ist nicht 100% aktuell) und aktuelles auf der Open Automation Mailingliste (SourceForge.net: Open Automation: openautomation-devel), bzw. im SVN Repository.

Aber:
Noch bin ich in der ersten Phase, wo ich ein Grundgerüst Skizziere, damit man etwas hat, über das man als Entwickler überhaupt reden kann. Da das noch nicht fertig ist, habe ich auch noch nicht wirklich nach Mitstreitern gesucht.

Habe mal ganz kurz in GrAF geschaut und das erscheint mir auf den ersten Blick ein bischen mit Kanonen auf Spatzen zu schießen :-)

GrAF nur als Multi-Protokoll-Backend zu nutzen ist zwar locker möglich, aber tatsächlich etwas arg groß dafür (vom Mindset, nicht von der realen Implementierung. Die ist ziemlich übersichtlich! Performance ist dank persistenter Verbindung zum Web-Server übrigens auch noch besser als das aktuelle Backend, das bei jedem Request neu gestartet wird...)

GrAF ist ja auch als Logik-Engine gedacht...

[netzkind]

AW: Alternatives Protokoll zum Übermitteln und Darstellen von Daten in der CV

Bei nochmaligen überlegen komme ich immer wieder auf die Idee zurück bei der address einen zusätzlichen Parameter wie "backend" einzuführen, mit denen man ein anderes backend für diese Adresse definieren kann.

So muß ein Backend nicht immer alle Protokolle sprechen können. Ich denke, dass das für zukünftige Implementierungen fast unumgänglich ist.

Wieso das denn? Jede Adresse definiert jetzt schon (oder sollte das zumindest) ihr Protokoll (knx:..) - wieso dann zusätzlich noch ein backend definieren? Das macht es dem Laien nicht einfacher in die CometVisu einzusteigen = no-go.
Auch ist es der Performance nicht zuträglich, wenn die Visu Verbindungen zu mehreren Backends offen halten muss, da sich dadurch Clientseitig mehr Netzwerk-Overhead ergibt (Akkulaufzeit? Maximale parallele Verbindungen?).

Ich votiere für ein Plugin-artiges Backend, das Serverseitig mit Providern redet um die Daten zu erhalten und "gesammelt" zu übermitteln.

PS: vielleicht verwechsel ich grade auch die DPT mit den GA was den Namespace angeht. Hab grade keine Visu da um nachzuschauen.

[Chris M.]

PS: vielleicht verwechsel ich grade auch die DPT mit den GA was den Namespace angeht. Hab grade keine Visu da um nachzuschauen.

Jain. Bei den Adressen erzwinge ich z.Zt. noch nicht den Namespace "KNX:", da das aktuelle Backend das eh (noch?) nicht kann. Und es aktuell keinen Mehrwert bringt.

Aber sobald etwas intelligentere Backends da sind (z.B. GrAF) wird es wichtig den Namespace anzugeben.
Aber auch da könnte man mit einem Default-Namespace arbeiten, d.h. alles ohne Namespace wird z.B. wie "KNX:" behandelt.

[netsrac]

Alternatives Protokoll zum Übermitteln und Darstellen von Daten in der CV

Wieso das denn? Jede Adresse definiert jetzt schon (oder sollte das zumindest) ihr Protokoll (knx:..) - wieso dann zusätzlich noch ein backend definieren? Das macht es dem Laien nicht einfacher in die CometVisu einzusteigen = no-go.

Hmm....nunja, sehe ich nicht ganz so - ich könnte mir vorstellen, dass es verschiedene Backends gibt - ähnlich wie im Moment per URL das CGI-bin definiert wird, kann man bei der Adresse das Default Backend überschreiben. Klar gibt der Namespace das Protokoll schon mit, aber wenn man mit verschiedenen Backends arbeiten will, dann müsste die CV ja den Namespace von der Adresse filtern und das entsprechende Backend aufrufen.

Ich denke einfach an einen zusätzlichen optionalen Parameter.

Was die Performance angeht, so stimme ich Dir da nicht so ganz zu. Die Anzahl der Adressen ist und bleibt gleich. Es ist lediglich eine zusätzliche Verbindung, die offen gehalten wird. Aber solange es nicht 20 Verbindungen zur gleichen Zeit sind, kostet nur der Verbindungsaufbau Performance.

Gruß, netsrac

[netzkind]

Was die Performance angeht, so stimme ich Dir da nicht so ganz zu. Die Anzahl der Adressen ist und bleibt gleich. Es ist lediglich eine zusätzliche Verbindung, die offen gehalten wird. Aber solange es nicht 20 Verbindungen zur gleichen Zeit sind, kostet nur der Verbindungsaufbau Performance.

Nach meinem Wissen ist die Zahl paralleler Verbindungen von mobilen Endgeräten nicht 20, sondern wesentlich niedriger (Ich hab hier als Notiz von 2011 die Zahl 4 stehen).

Grade im Hinblick auf mobile Endgeräte halte ich auch deine Aussage über "nur der Verbindungsaufbau kostet Performance" für wagemutig.

Ich bleib also weiter dabei: die Datenverbindung ist der/die/das Bottleneck, da nur so wenig wie möglich machen.

Aber "wer es umsetzt entscheidet".

[greentux]

Naja, das kommt auf die Verteilung an:
WLAN
UMTS
EDGE
GPRS

Bei letzterem würde ich mir um die Datenrate Sorgen machen... Aber wer macht damit Visu???

[netzkind]

Naja, das kommt auf die Verteilung an:
WLAN
UMTS
EDGE
GPRS

Bei letzterem würde ich mir um die Datenrate Sorgen machen... Aber wer macht damit Visu???

Ich rede nicht von der Datenrate, die ist - unabhängig von einem oder mehreren Connects - vergleichbar, da nur die anfallenden Daten übertragen werden, unabhängig von der Anzahl der Verbindungen.

Ich rede ausdrücklich NUR von der Anzahl der Verbindungen, da diese meiner Ansicht nach Auswirkungen auf das Endgerät haben, im Sinne der Performance und mglw. Akkulaufzeit, ganz abgesehen von technischen Einschränkungen bei der Zahl der parallelen Verbindungen.

Aber probiert das ruhig selber aus :-)

[swiss]

Könnte man denn dem Backend einfach eine art Pluginschnittstelle spendieren? Dann bräuchte man nur EIN Backend dass auch nur EINE Verbindung pro Client offen hällt. Aber man könnte praktisch beliebig viele "Schnittstellen" an das Backend koppeln. Das wäre ja fast das gleiche wie mehrere Backend's zu erstellen. Jede Schnittstelle könnte ein eigenens "Plugin" sein. So kann jeder selber entscheiden was er braucht und was nicht. Und auch neue Schnittstellen/Protokolle wären leicht integriert.

[Chris M.]

Könnte man denn dem Backend einfach eine art Pluginschnittstelle spendieren?

1. Ja, man könnte, siehe:
2. GrAF hat das genau so jetzt schon. Ist völlig unabhängig von der Logik Engine, die GrAF auch noch werden soll.

[netsrac]

Alternatives Protokoll zum Übermitteln und Darstellen von Daten in der CV

Okay....dann erzähle uns doch mal, wie GrAF funktioniert und wie wir es aufsetzen können :-)

[Chris M.]

Gerne (zumindest erst mal den hier aktuell relevanten Teil) - aber bitte auf der Mailingliste (SourceForge.net: Open Automation: openautomation-devel), da das (noch) nichts mit der CometVisu zu tun hat

[greentux]

Dort läuft doch aber noch die C++11, gcc und viel zu neu fürs WG Diskussion...

[Chris M.]

Richtig - und deswegen die GrAF Diskussion bitte dort und nicht hier.