Web-UI in eigenes Repository (war: [PATCH v4 1/1] Add Leaflet-Map Position selector)

Mi Jan 27 10:44:09 CET 2016

Hallo delphiN,

Am Dienstag, 26. Januar 2016, 21:24:56 schrieb delphiN:
> Am 26.01.2016 20:09, schrieb Tobias Klaus:
> > Ich denke am einfachsten wäre es hier einfach mal zu skizzieren was
> > du so vor hast. Jeder der an der Entwicklung beteiligt ist kann
> > sich dann damit abstimmen oder Anmerkungen machen. Damit könnte man
> > doppelte Arbeit sparen und schon im Vorfeld einen entsprechenden
> > Austausch mit den Aktiven pflegen.
> 
> Als erstes würde ich ganz gerne mal bestehende JavaScript Warnungen
> und Fehler fixen und die ganze Oberfläche auf das Pure-UI-Framework
> umstellen um dieses 90er-Jahre-Flair loszuwerden. Damit hat ja Dominik
> schon angefangen. Hier kann man sicherlich zusammenarbeiten.
Das klingt doch gut.

> Ein UI sollte möglichst nie direkt mit den Internas verknüpft sein.
> Falls es hier eine starre Bindung gibt sollte diese meiner Meinung
> nach durch eine API aufgelöst werden.
> 
> Eine derartige Integration in das System kann ich allerdings gar nicht
> erkennen. Es geht mir eigentlich nur um das package "fff-web". Dort
> werden eigenständige cgi-skripte aufgerufen die man auch beliebig
> austauschen könnte. Ganz zu schweigen vom html, css und Javascript.
Ich denke wir wissen alle was eine Schnittstelle ist und wofür sie genutzt 
wird. Wie du aber gesehen hast sind erst kleine Teile der Funktionalität in 
der Firmware enthalten und da liegt auch das von mir angesprochene Problem. 
Wir haben noch keine feste API und die wird auch erst durch Patches entstehen, 
die diese API implementieren. Wir werden also in nächster Zeit ganz viele neue 
API-Versionen sehen. Die werden vermutlich schöne Schnittstellen 
haben(deswegen machen wir ja Peer-Review), aber die werden erstmal eher nicht 
als einzelne API-Versionen dokumentiert werden. Sondern eben in der 
Referenzimplementierung genutzt. Um die volle Funktionalität ausnutzen zu 
können, muss man also immer auch an der Entwicklung der Firmware dran bleiben.
Noch blöder ist es immer unterschiedliche Repos synchron zu halten. Das lässt 
sich einfach am einfachsten direkt miteinander entwickeln.

> Damit eine UI für Franken verwendet werden kann muss es halt die
> nötigen nodewatcher-Daten bereitstellen. 
Das ist nur für das monitoring nötig und wird auch nicht von der Weboberfläche 
gemacht, nicht mal von selben Paket.

> Letztendlich entscheidet Ihr
> welches Web-Interface in eure Firmware kommt. Ich seh da ehrlich
> gesagt nicht das Problem.
Meiner Meinung nach entscheidet das schlussendlich sogar der Nutzer.

> > Auch wenn es mal andere Oberflächen geben wird(siehe Kommentar
> > unten) wird die aktuelle Weboberfläche erstmal sowas wie eine
> > Referenzimplementierung sein.
> 
> Als Referenzimplementierung ist sie auch sehr brauchbar. Will man sie
> aber durch Alternativen wie z.B. luci2 oder z.B. eine reine API für
> eine native Knoten-Managemant-App ersetzen muss man erst die
> bestehenden Webseite aus der firmware "herauskratzen". Das geht jetzt
> noch deutlich einfacher als in ein paar Monaten!
Was verstehst du unter herauskratzen und was würde es dir helfen sie über 
einen internen Feed einzubinden? In beiden Fällen müsstest du nur einen 
zusätzlichen Feed einbinden und ein anderes Paket auswählen. Ein externes 
Repository bringt hier wirklich keine Verbesserung.

> > Weshalb Feature-Requests und Bugreports für die Weboberfläche
> > getrennt von denen für die Firmware verwaltet werden sollten
> > erschließt sich mir auch nicht so recht.
> 
> So eine Web-Interface ist keine funktional wichtige Komponente. Hier
> kann man auch mal schnell ein paar kleine CSS-Verbesserungen machen
> ohne, das gleich ein paar Spitzen-Ingenieure darüber schauen müssen,
> damit nichts "explodiert". Die Entwicklung könnte hier wesentlich
> schneller und unkomplizierter werden und auch Menschen zumindest
> einbinden, die sich nicht so tief in OpenWrt einarbeiten wollen. Das
> wäre eine tolle Möglichkeit die Entwicklung wieder etwas zu öffnen und
> mehr Mitarbeit nach den eigenen Möglichkeiten zuzulassen. Ich halte
> das für dringend notwendig.
Nur um das Mal festzuhalten: Es gab noch nie so viele Firmwareentwickler und 
Schultern die gemeinsam das Netz tragen als aktuell. Richtig angefangen hat 
das in dem Moment, als wir uns für einen Arbeitsfluss entschieden haben und 
über die Liste eine für alle Interessierten transparente Entwicklung begonnen 
haben. Dass du dir das anderst vorstellst ist hinlänglich bekannt und ich 
denke auch allen bewusst. Es gibt trotzdem einen Konsens das erstmal so zu 
lassen. 

> > Auch hier wäre natürlich ganz interessant, mehr über deine Pläne zu
> > erfahren.
> 
> Ich habe mir Anfang diesen Jahres Zeit genommen mich in neue
> Technologien und Web-Frameworks einzuarbeiten. Hier würde ich evtl.
> eine zweite "Referenzimplementierung" mit eher experimentelle Features
> machen, wenn ich die Zeit und Muse finde. Hier schweben mir z.B.
> Live-Graphen, Last-Diagramme, Drag-And-Drop Interface-Management usw.
> vor. Ähnliche Features wie es z.B. die Ubiquity-Firmware oder eine
> Fritzbox heute mitbringen.
Das klingt doch gut. Wäre aber in der offiziellen Oberfläche genauso gut 
aufgehoben. Aber wie gesagt, es spricht ja nichts dagegen sich da auch selbst 
zu verwirklichen.

> Wenn Ihr das bestehende Web-Interface ausgliedert wäre ich bereit alle
> Verbesserungen daran als saubere Patches über die Liste einzureichen
> und Änderungswünsche auch über die Mailingliste entgegenzunehmen (auch
> wenn sich mir dabei die Fusnägel aufrollen). Die Kontrolle an dem
> neuen Repository "fff-web" könnte voll beim bestehenden
> "firmware-development" Team bleiben. Ich will euch nichts wegnehmen
> sondern einfach Mitarbeiten ohne mich zu verbiegen!
Schön, dass du dich doch an der gemeinsamen Entwicklung beteiligen willst. Den 
Vorteil eines separaten Repositories sehe ich aber immer noch nicht. Auch wenn 
ich mich wiederhole: Es ist der selbe Vorgang ein anderes Web-UI einzubinden. 
Egal woher das "erste" kommt.

> Diese Ausgliederung würde es mir deutlich vereinfachen parallel mit
> weiteren Implementierung zu experimentieren ohne auf die wichtigen
> Änderungen an der Firmware verzichten zu müssen.
Auch hier einer zusätzlichen experimentellen Oberfläche steht nichts im Weg. 
Ich habe auch kein Problem damit, einen Patch einzuspielen, der den Feed für 
diese Oberfläche mit einbindet und die Abhängigkeiten des Basispakets so 
anpasst, dass beide Oberflächen ausgewählt werden können.
Das wären übrigens Schritte die für beide Modelle (zwei Oberflächenfeeds/nur 
ein zusätzlicher Oberflächenfeed) notwendig wären.

Am Ende bleibt für mich tatsächlich nur der von Dominik erwähnte Vorteil, dass 
die Pfade nicht mehr so lang sind, der für ein heraustrennen sprechen.

Daher mein Vorschlag an dich: Du beteiligst dich wie von dir vorgeschlagen an 
der Weiterentwicklung und Verschönerung der aktuellen Oberfläche und legst dir 
parallel dazu dein eigenes Repository an. Wenn du den entsprechenden Patch 
einreichst, wäre ich bereit, den neuen Feed einzubinden und ihn so allen 
Firmwarebauern zugänglich zu machen. Da ich keine Änderungen am Repository 
allein vornehmen kann, müssen wir das natürlich absprechen, aber ich denke 
wenn das ordentlich gemacht ist, werden die anderen nichts dagegen haben.

So können wir von deiner Erfahrung in der Entwicklung von Weboberflächen 
profitieren und du kannst weiter komfortabel an einer moderneren Alternative 
experimentieren.

Viele Grüße
Tobias
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20160127/ef13e0b4/attachment-0002.sig>