Ideensammlung xxAPI2

[NilsS]

So da ja nun auch schon Gerüchte durchgesickert sind bzgl. der xxAPI2 hier nun mal ganz offiziell.

Derzeit besteht die xxAPI2 lediglich in der Theorie aber wir können ja schonmal ein paar der gedachten Dinge festhalten so das Ideen und Kritik schon vorher einfließen können.

xxAPI2

* Die xxAPI2 ist nicht wie bisher eine Sammlung von Dateien, sondern ein Logikbaustein, der so auch die Installation vereinfacht.
* Es basiert auf der gleichen Technik, die auch beim Logikbaustein 12251_Proxy Dateien dynamisch unter http:/hsip/opt/... zur Verfügung stellt.
* Die xxAPI2 wird zur xxAPI kompatibel sein, jedoch wird Sie nicht über ein iKO befüllt, sondern durch eine integrierte ajax.js.
* Die APP's (VLC,Balken,Schnee....) werden auch direkt in diese ajax.js integriert.
* APP's und xxAPI werden also nicht mehr über die xxAPI-INIT Seite geladen, was diese schlanker und schneller macht (deutlicher Vorteil beim XXMODUL)
* Die Konfiguration findet nur noch mittels Browser statt. Auf der Konfigurationsseite wird ausgewählt welche xxAPI Version und welche APP'S welcher Version integriert werden sollen, und welche User über welche Einstiegs-URL Zugriff haben.
* Die Daten werden ähnlich dem Baustein Telefonbuch und SystemLog in einem iKO Buffer gespeichert um sie unabhängig vom Internet zu machen
* Die Daten der xxAPI werden über eine in die Logik integrierte Webabfrage geholt, das bringt leider nicht nur den Vorteil das damit alles geholt und in genau das richtige Format gebracht wird, sondern auch den Nachteil das Daten nicht transparent übermittelt werden. Ich weiß das das ein großer Sicherheitsaspekt bei vielen sein wird, aber was anderes fällt mir da derzeit nicht ein. Ob es vielleicht einen Dateneingang gibt mit dem optional Daten eingebracht werden weiß ich noch nicht. Wer da also Ideen hat bitte .
* Die geholten Daten werden mit mit einer MD5 Checksumme geprüft.
* Der Baustein wird leider nicht OPEN-Source sein, da er einige Teile enthalten wird, die wir (PLAYGROUND-Team) als nicht öffentlich eingestuft haben. Der JavaScript anteil, also die eigentliche xxAPI bleiben jedoch GPL. Der Rest des Baustein wird wie auch viele andere Bausteine aus dem Playground auch nach CC-BY-SA 3.0 lizensiert, was eigentlich fast die gleichen Rechte zwecks Nutzung hat wie auch die GPL, jedoch nicht vorsieht das der Quelltext offen sein muß.

[kippi]

Sodele ich hab abgestimmt

Da meine gesamte Visu mittlerweile auf xxapi läuft und dies sogar sehr gut, bin ich schonmal gespannt was xxapi2 bringen wird.

Anfangs hats bissl gedauert mit dem xxapi Programmieren, mittlerweile gehts ruck zuck. Wobei ich gegen Erleichterung und Verbesserung der Programmierung nichts einzuwenden habe. Performance ist immer gut und die "Transparenz" sollte auch nicht ausser Acht gelassen werden.

Also kurz um gesagt, die Mischung machts und ich denke das schafft das Playgroundteam

[NilsS]

Punkt 4 ist leider von mir schlecht gewählt, hab da aber gerade die Admins gebeten das zu korigieren.

Mit Sicherheit war eigentlich etwas anderes gemeint. Ich würde nichts einbauen was die Sicherheit verschlechtert

Gemeint war damit lediglich das der Baustein Daten von extern(KNXUF-Server) läd, ohne das du das siehst was er läd noch wann er es läd und was er dabei überträgt.

Ich würde das zwar vorher genau beschreiben, aber es gibt viele die mich schon bei der xxAPI danach gefragt haben und die xxAPI nicht mittels Webabfrage, sondern nur per HSMonitor übertragen.

[kippi]

Das ist schon verständlich, konnte ja aber jeder bei xxapi selbst entscheiden ob er die Daten laden lässt oder selbst einspielt.

So schnell wie Ihr Neuerungen rausbringt komm ich garnicht dran zum rumprogrammieren (zum Leid meiner Freundin ^^)

Weiter so !!

[jumper79]

Hallo Nils,

Gibt es schon einen geplanten Releasetermin?

[NilsS]

Ich hab noch nicht mal angefangen

Die Ideen sind zwar alle dar, auch wie es technisch umgesetzt wird, aber:

1.) Die jetzige ajax.js ist
2.) Eine komplett neue Objektorientiert zu bauen ist auch nicht mal ebenso ~2000-3000 Zeilen Code + framework
3.) Warum sollte ich die jetzt (mal eben) für Dacom/Gira bauen ?
4.) Ich hab nicht mal ne Visu, derzeitiger Visustand (~5%) ansonsten HS-qMon (makki)
5.) Es wird bestimmt was kommen, aber warten wir's mal ab. Im Moment erstmal weiter im Logikbereich.

[makki]

4) dito
Der CometVisu-to-KOGW-daemon ist aber in pre-alpha fertig, fehlt "nur" noch die Visu dazu

Makki

[atlatus]

Hallo Nils, ich persönlich hätte Probleme, so ein grosses, kompaktes Stück Software einzusetzen, und darauf meine Visu abzustützen. Die XXAPI ist noch relativ überschaubar (und macht trotzdem noch genug Probleme). Und es gibt den Sourcecode (falls du mal unters Auto kommst, oder keine Lust mehr auf HS hat, was wir alle nicht hoffen wollen).

Das "verstecken von möglichst viel Funktionalität in compiliertem Code" ist dieselbe Philosophie, wie sie auch im Quadclienten steckt. Nur das da ein Konzern mit einer 24h Hotline dahintersteht, und ein Kaufvertrag, der mir Gewährleistung und Garantie bietet. Und das auch die nächsten 10 Jahre.

Von der Dokumentation (bzw. dem Mangel derselben) mal ganz zu schweigen. Und eine noch engere Anbindung an den proprietären knx-user-forum Server ist auch nicht in meinem Sinne.

Also wenn ich schon umsteigen müsste (sehr widerwillig), da mir sonst wesentliche Erweiterungen entgehen würden, dann würde ich auf den QC wechseln. Und das ist sicher nicht in unserem Sinne.

gruss peter

[MatthiasS]

Und das ist sicher nicht in unserem Sinne.

gruss peter

Ich weiß nicht, ob du hier für UNS sprechen kannst. Maximal für dich!

Im Übrigen hat das knxuf den Quellcode für alle codierten Module sicher verwahrt.

[atlatus]

Ja, du warst auch gar nicht gemeint. Ich meinte mit UNS Mich und Nils. Mich, weil ich XXAPI sehr schätze und gerne einsetze, und Nils, weil er sich Arbeit machen wil, die dann doch nur dazu führt, dass die Anwender auf Sicht lieber zum QC wechseln. Was auf Dauer eh im Raum steht, wenn die neuen Gira Bausteine nur noch eine QC Anbindung haben werden...

Also mach dir keinen weiteren Kopf...

[NilsS]

Also nochmal kurz zusammen gefasst.

ALLE Quelltexte sind im internen Bereich veröffentlicht.

Das ich diese Quelltexte nicht veröffentliche hat nix damit zu tun, dass ich sie für mich behalten möchte, sondern lediglich zum Schutz vor Mißbrauch.

Es geht darum das aus dem ByteCode-Bausteinen quasi alles möglich ist, was im einzelnen nun dazu führen könnte, dass Gira/Dacom diverse Dinge schließen müssten, will ich hier jetzt nicht breittreten. Es geht doch eher darum das wir die Möglichkeiten des ByteCodes behalten wollen um auch die vielen anderen Bausteine weiter nutzen zu können.


Speziell bei der xxAPI wäre eigentlich nicht viel was CLOSED-Source sein müsste, lediglich der Teil der zum remanent-speichern verwendet wird (wie auch bei hshpone).

Aus meiner Sicht könnten alle Bausteine (ok - abgesehen von hsfusion ) GPL sein.

Der Logikbaustein der xxAPI würde auch nur quasi ein loader sein, der eine ajax.js oder wie auch immer, zur Laufzeit des HS unter /opt/hsav... plaziert.

Der Baustein würde mit der hier veröffentlichten KNXUF_urllib die Daten lediglich von da abholen wo sie jetzt auch schon liegen.

Der Unterschied wäre aber das die "ajax.js" schon alles enthällt und somit die INIT-Seite nicht bei jedem Aufruf xxAPI und weitere APPS laden muss.


PS: Ich mach die meisten Dinge einfach nur weil ich sie auch brauche, zwar häng ich ganz schön hinterher aber irgendwann werd ich xxAPI & Co auch einsetzen.

[daniel.duese]

aber irgendwann werd ich xxAPI & Co auch einsetzen.

...ja, wenn Dir Uwe eine Visu baut.


Da ich Dich kenne, habe ich auch keine Angst die Bausteine und die xxAPI einzusetzen. Egal ob open- oder closed Source. Daher spielt es für mich keine Rolle und kenne keinerlei Skrupel...

[atlatus]

Nils, warum sparst du dir nicht komplett die Arbeit mit dem dynamischen Update und dem Loader. Eine Visu wird einfach nicht online upgedated wie windows. Sondern man hat eine stabile Konfiguration, die bei einer neuen Version mit dem Experten überschrieben wird.

Wenn das bisherige XXAPI mal installiert ist, braucht man sich ja auch nie wieder darum zu kümmern. Es sei denn, es gäbe mal eine neue Version. Dann wird die Datei XXAPI.diff gewechselt, und gut iss. Schon bei XXAPI ist das dynamische Nachlade-knx-Doppelmopel eher störend als nützlich.

Es ist auch nicht notwendig, per Browser neue Erweiterungen zu laden. Denn danach muss man sowieso mit dem Experten die ganze Mimik einbinden. Oder willst du eine komplette QC nachbauen?

Die Quelltexte an sich sind mir egal, es kommt eher darauf an, dass man im "Ernstfall" auch eine Alternative drumrum Programmieren könnte.

Je einfacher du alles hälst, und je besser das dann noch dokumentiert ist, desto besser. Und mit einfach meine ich keinen automatischen Download. Wer den HS programmiert, der kriegt das auch gerade noch manuell hin...

gruss peter

[NilsS]

Naja du hast ja bedingt recht, das man eigentlich nichts an der Visu rumschraubt, aber ich geb dir mal ein paar punkte warum ich das sinnvoll finde.

1. neue Browser (vorher nur ABFRAGE IE dann mache xxx, jetzt z.B. IE9 kann canvas)
2. Bugs in den xxAPPS (z.B. Balkendiagramm, ein unewarteter Wert im Minus lässt das Bild unsauber darstellen)

3. Neuerungen in den xxAPPS (neu VLC Version zeigt jetzt standardmäßig den Filenamen an)

4. Skins für die POPUPS dynamisch laden.

Es bliebt aber weiterhin so, es geht IMMER auch alles statisch. Man muss es nur selbst zusammenklicken.

Jetzt heißt das xxAPI per Browser laden und in das iKO, später heißt das dann halt ajax.js laden und manuell in das hsupload/... Verzeichniss.


bzgl. deines händischen hinzufügens.... genau da entstehen aber doch die Fehler die Zeit kosten im Support.



Derzeit hab ich genau dieselben Probleme mit Rollladen, Heizung und Konsorten.
Jeder braucht es aber jeder klickt sich alles selbst zusammen.

Wenn man eine fertige Bibliothek hat die man verwenden kann und nur verbinden muss dann kann man auch weniger falsch machen.

Ich vertraue da inzwischen Objektorientierten Logikbausteinen mehr als den konventionellen und auch als dem GLE.

genannte Bausteine sind als Konzept schon vorhanden und erlauben (zumindest in Gedanken) schon eine hierarchische Anordnung dieser Elemente und erlauben solch einfache Dinge wie Vererbung/Gruppierungen ....

[atlatus]

1. neue Browser (vorher nur ABFRAGE IE dann mache xxx, jetzt z.B. IE9 kann canvas)

Mir würde es ehrlich gesagt voll reichen (bei dem Leistungsumfang des HS), wenn IE8 mit den Standardfeatures einwandfrei laufen würde. Meine Visu nutzt nicht ein Bruchteil aller IE Features aus.

2. Bugs in den xxAPPS (z.B. Balkendiagramm, ein unewarteter Wert im Minus lässt das Bild unsauber darstellen)

3. Neuerungen in den xxAPPS (neu VLC Version zeigt jetzt standardmäßig den Filenamen an)

Warum man dafür diesen Aufwand treiben muss und das nur dynamisch gelöst werden kann, durchschaue ich jetzt nicht.

4. Skins für die POPUPS dynamisch laden.

Nuja, ich kann die Skins auch vorgeben. Ich sehe im Moment keine HS applikation, die das irgendwie erfordern würde.


Es bliebt aber weiterhin so, es geht IMMER auch alles statisch. Man muss es nur selbst zusammenklicken.

Das muss man beim HS endeffektlich sowieso. Bei jedem kleinen Fuzzelchen, jedem Rolladen, jeder Zeitsteuerung..., die man in dem HS programmiert. Geschweige denn, wenn man eine Applikation auf Basis des Demoprojektes macht. DAS ist Arbeit, unabhängig von der XXAPI.

Jetzt heißt das xxAPI per Browser laden und in das iKO, später heißt das dann halt ajax.js laden und manuell in das hsupload/... Verzeichniss.

Und was spare ich mir damit? ausser ein paar sekunden beim hochfahren des HS? Ist das wirklich ein Problem?
Bei mir starten nach dem Hochfahren 30 Webabfragen. DAS ist langsam...

bzgl. deines händischen hinzufügens.... genau da entstehen aber doch die Fehler die Zeit kosten im Support.

Support? welcher Support? ausser von dir gibts wenig hilfreiches :-)

Ich denke, eine genügend einfache und ausführliche Dokumentation würd da Wunder wirken. Schon bei den bisherigen Projekten. Ich bin da durchaus bereit (allein aus Eigennutz) daran mitzuwirken... Zusammen mit eine überschaubaren Projektdokumentation und Downloadmöglichkeit, wie sie in anderen Foren usus ist.

Derzeit hab ich genau dieselben Probleme mit Rollladen, Heizung und Konsorten.
Jeder braucht es aber jeder klickt sich alles selbst zusammen.

Wenn man eine fertige Bibliothek hat die man verwenden kann und nur verbinden muss dann kann man auch weniger falsch machen.

Ich vertraue da inzwischen Objektorientierten Logikbausteinen mehr als den konventionellen und auch als dem GLE.

Ja eben. Jeder klickt sich alles zusammen. Und es funktioniert. Und beim klicken bleibt es auch, wenn ich deine Bibliotheken in eine Applikation einbinde (Statisch oder dynamisch). Da muss ich dann neue Fenster bauen, die in das Demoprojekt einbinden, die Verweise richtig nachführen... DAS ist die Hauptarbeit. Und die Hauptfehlerquelle. Genau deshalb hat Gira ja QC gemacht, um genau das zu umgehen...

genannte Bausteine sind als Konzept schon vorhanden und erlauben (zumindest in Gedanken) schon eine hierarchische Anordnung dieser Elemente und erlauben solch einfache Dinge wie Vererbung/Gruppierungen

Schön. Nur allen Ernstes: deine Bausteine (so gut sie auch sind) sind für die Mehrzahl der Nutzer jetzt schon zu kompliziert und Aufwendig. Und viel zu wenig Dokumentiert. Da willst du nochwas draufsetzen?

Alles was du sagst hat als letztliche Konsequenz, dass du ein Konkurrenzprodukt zu QC bauen musst, und du hast weder die Manpower noch den finanziellen Background, das zu machen. Zumal du ja gar kein Geld damit verdienen kannst/willst. Gira verkauft dadurch wenigstens HS und Visus...