Ideensammlung xxAPI2

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

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

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

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

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

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

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

[makki]

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

Makki

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

[jumper79]

Hallo Nils,

Gibt es schon einen geplanten Releasetermin?

[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 !!

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

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]

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ß.