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

[delphiN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 aktuelle Web-UI ist integraler Bestandteil der aktuell ziemlich
>  tiefgreifenden Weiterentwicklung der Firmware selbst,
> beispielsweise was den dezentralen Umgang mit Hoods und Knotendaten
> angeht. Ich denke nicht, dass es Sinn macht das hier zu trennen.

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.

Damit eine UI für Franken verwendet werden kann muss es halt die
nötigen nodewatcher-Daten bereitstellen. Letztendlich entscheidet Ihr
welches Web-Interface in eure Firmware kommt. Ich seh da ehrlich
gesagt nicht das Problem.

> Wie schon gesagt, macht eine solche Trennung eigentlich keinen
> Sinn, einerseits brauchen wir meines Erachtens nicht noch einen
> Kanal und nicht noch ein Repository, andererseits sind die
> "Internals" eben doch recht eng verknüpft.

Die Firmware ist schon heute von min. 3 weiteren Repositories
abhängig. Auch hier werden ja nicht einfach die Sourcen kopiert
sondern extern gezogen. Aus meiner Sicht macht eine Aufteilung in
Module fast immer "Sinn".

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

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

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

Auch habe ich bereits mit luci2 auf einem normalen OpenWrt einige
Erfahrung gesammelt und würde das auch gern bei uns zum laufen bringen.


Letztendlich kann ich ja jederzeit das Repository forken und meine
Änderungen vornehmen. Genau das habe ich ja auch schon getan.
Aber es ist glaube ich weder für mich noch für "euch" wünschenswert,
wenn wir an einander vorbei arbeiten.
Mein Plan ist eigentlich jede größere Änderung in einem eigenen
Feature-Branch zu machen und euch diesen als Pull-Request bei
Github/Gitlab bereit zu stellen. So arbeite ich und alle Firmen bei
denen ich bisher war Tagein Tagaus und ich sehe absolut keinen Grund
mich hier (wegen Einzelpersonen) zu verbiegen. Wenn Ihr
Fehlerbehebungen oder neue Features haben wollt ist es eure Aufgabe
euch die zu holen und nicht meine die den Hohenpristern auf dem
Silbertablet vorgekaut vorzusetzen!
Mit so einer Einstellung kommen wir uns aber wohl nie näher, deshalb
wäre ich für einen Kompromiss bereit:

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!

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.

Könntet Ihr damit Leben? Wie sehen das die Anderen?

delphiN

- -- 
Freifunk-Franken, Förderverein Freie Netzwerke e.V.
eMail: freifunk at wunschik.net
XMPP : delphiN at jabber.ccc.de

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJWp9YYAAoJEGuH2dOBPapClbMP/0IgFB+lb6gEVhLNY2xBz3tF
mwlvScoK+MrcOP90rHg0juKgo+iuRF41zB92evusCP6vlvP6ZYn2g5dyMueUWm8O
k4XXPFAKXSwEKLoVGHF3knVv9ZmN9yFJVd++IMmCZwdU5PO1Lbz9yCXUQp8JY5XP
8QvPG0CBtfruNQYUI5lr3gp8R/+UxsdzdSP/0vSzMLcDu4i5bnekcEYxknJNJ5za
2CSTddE+4J9OxmAa+XfxtFHZ+HcTH5QiWh5852VMrTodnAiXM46GmDSLghOFX/bU
5nMR1GNg+7uNzRyA76e1eHGo2s7tUahf3YDtkp49bqFD+4tVtbvSUV/A0R/Kg6KL
9tE3kYagpiqT1LE2HarfAoyjd7rsVhq8P4QFk6j6KJlf4in8FwTiFP/TWYxlijDN
KdndxVO0a/crM7kEqbCGJ0roDs3R5iDue4sRkrSXjs/DI+9gSLswBV7VP4DXg0/Z
jpsVny+UBsy98gfDAMnXOB2SmW6fnPT050eb1IQNQQD36NS/Ozw9s6CO8Rf8BfAa
mGS1tNTxsmPEd5rhmke5xTYWxrr+zOyCSjBBQw8BdME1T81HSzR2h2RAMDdptX34
dNWCUNnFNw4EVrvW8LvaDaFKsGYZ87l993YLlERHSC+z4eCo8aKfJ0pCt0Iz3KGj
BJQJZQC69we9nywEi9FE
=EnX8
-----END PGP SIGNATURE-----