Yanosz am 28. November 2014 um 15:28 Uhr

2014-11-28T15:28:42Z

Yanosz: Die Seite wurde neu angelegt: „== Einleitung == Der 31c3 steht vor der Tür und damit die Chance mit Freifunkern Ideen und Erfahrungen auszutauschen. Gleichzeitig sind wir mit der Umsetzung…“

2014-11-28T15:26:54Z

Die Seite wurde neu angelegt: „== Einleitung == Der 31c3 steht vor der Tür und damit die Chance mit Freifunkern Ideen und Erfahrungen auszutauschen. Gleichzeitig sind wir mit der Umsetzung…“

Neue Seite

== Einleitung ==

Der 31c3 steht vor der Tür und damit die Chance mit Freifunkern Ideen und Erfahrungen auszutauschen. Gleichzeitig sind wir mit der Umsetzung der [[Anforderungen]] weitesgehend fertig -- wenn man von Crypto absieht.

Mit dieser Wiki-Seite möchte ich gerne eine Diskussion-Starten, in welche Richtung wir in Zukunft weiterarbeiten.

Gruß, Jan

=== Zukunft: register.kbu.freifunk.net ===
Meine Idee für die Anwendung war eine Art Wiki-Ansatz: Es gibt einen Server mit Webanwendung, in der jeder eine Seite zu "seinem" Knoten anlegen kann und dazu weitere Infos bekommt.
Die Anwendung ist technisch ziemlich alt (-> Rails Upgrade steht an) und kommt aus einer Zeit, inder alle Communities unübersichtliche Wiki-Tabellen für ihre Knoten gepflegt haben. (Lübeck hatte damals sogar eine Wiki, aus der ffmap Knoten parsed hat).

Hierbei hab' ich aber viele Fragezeichen
# Trifft der Ansatz die Benutzererwartung?
# Wie sollen die Use-Cases (Node-Daten bereitstellen, Node-Daten abrufen) aus Benutzersicht ablaufen?
** Im Config-Mode?
** Durch eine Register-Seite?
** Ganz anders?
# Wollen wir im Config-Mode Internet bereitstellen um eine Kartenposition zu suchen (afair nicht in gluon). Welche Konsequenzen ergeben sich für den config-Mode?
# Welche Informationen stellen wir da (-> Chat, Nodekontakt, etc.). Wie sollen Benutzer sie finden?
# Wo legen wir die Informationen ab? Alfred, MySQL-Datenbank? NoSQL-Datenbank, clustered auf Supernodes...
# Verhältnis zum Raketenkontrollzentrum
** Existieren beide Parallel?
**Wird eins in das andere eingebettet?
** Schnittstellen?

Ich hab' hierzu keine feste Meinung und bislang auch wenig überzeugende Argumente / Ideen gehört.
Wichtig wäre mir vor allem die Use-Cases aufzuschlüsseln ohne direkt über technische Details zu reden - ich denke, dass wir damit eine Sprache finden, die keinen abhängt.

In diesem Kontext kommt auch die Port-Belegung, das dezentrale Chat-System und ggf. auch avahi zum Zuge
* These: Ein Benutzer, der ein Kabel in einen LAN-Port steckt, erwartet dort eine IP zu bekommen um den Router erreichen / konfigurieren zu können
* These: Der config-mode braucht wlan-Support, da es immer mehr Geräte ohne LAN-Port gibt
* These: Der config-mode muss an OSM-Daten kommen können, damit dort Standortdaten der Nodes konfigurierbar sind
* These: Webseiten-Besucher wollen Daten zum Netz sehen. Was liefern wir? Register? Wiki? Map? Wollen wir die ffmap um Informationen anreichern?
* These: Benutzer sollten sehen können, mit welchem Node sie verbunden sind und wie sie den Administrator bei Problemen erreichen können (aktuell: E-Mail Kontaktfeld in register)

Aus den letzten beiden Thesen kommen ein paar Punkte:
* Warum machen Node-Aufsteller falsche Angaben / nutzen nicht-funktionierende E-Mail Adressen als Kontaktadresse in register?
** These: Sie wollen nichts über Probleme hören oder haben kein Interesse an der Kontaktaufnahme mit Nutzern
** These: Register ist ein "Telefonbuch" wo zu einem Node eine Kontaktmöglichkeit hinterlegt wird. Register ist sinnlos, wenn es falsche Kontaktadressen beinhaltet. Die gibt es, also ist register sinnlos.

=== Neue Firmware-Releases / Folgen des Gluon / LFF upstreams ===
# Welche Software-Pakete / Features wollen wir aus gluon nutzen?
** Zur Zeit verwenden wir bspw. nicht das batman-adv-Paket, da es mit der Visualisierung Probleme gab - gibt?
** Den autoupdate wohl nicht
** config-mode / expert mode wikt eher schwer
** Build-Prozess site-file: Eher nicht, schränkt den build stark ein
# Wie weit wollen wir uns konzeptionell an gluon annähern, bzw. gluon an un?
** Unterstützen wir Christof bei dem Ansatz, collectd und auto-key-upload in "gluon aufzunehmen"?
** Was bedeutet "aufnehmen" eigentlich an der Stelle?
# Was stört uns an Gluon?

=== batman-adv Migration ===
# Da müssen wir wohl durch - irgendwie
# Johnny Bee hat einen Test - gibt es Ergebnisse?
# Sind die aktuellen batman-adv releases stabil?

=== Raketenkontrollzentrum ===
# Was ist das eigentlich technisch? Eine JavaScript-Anwendung für Nodes?
# Eine Android / iPhone App? Eine monolithische Webapp?
# Wie intergriert sich das Zentrum in die bisheringen Dinge? Wer liefert welche Daten?
# Wann gibt es ein Release?

=== Doku ===
* Serverdoku - aktueller Stand?
* Schreiben wir nochmehr Konept-Doku für andere Communities?

=== Sonstiges ===
# QoS:
** Wie verhindern wir, dass eine Überlast-Situation das Netzwerk hart trifft?
** Wer hat Erfahrung mit QoS. Evtl. macht Jan dazu mal eine Session mit PEra
# FFFM: Was hat Christof für Pläne und Visionen

← Nächstältere Version		Version vom 28. November 2014, 17:28 Uhr
Zeile 14:		Zeile 14:
	# Trifft der Ansatz die Benutzererwartung?		# Trifft der Ansatz die Benutzererwartung?
	# Wie sollen die Use-Cases (Node-Daten bereitstellen, Node-Daten abrufen) aus Benutzersicht ablaufen?		# Wie sollen die Use-Cases (Node-Daten bereitstellen, Node-Daten abrufen) aus Benutzersicht ablaufen?
	** Im Config-Mode?		## Im Config-Mode?
	** Durch eine Register-Seite?		## Durch eine Register-Seite?
	** Ganz anders?		## Ganz anders?
	# Wollen wir im Config-Mode Internet bereitstellen um eine Kartenposition zu suchen (afair nicht in gluon). Welche Konsequenzen ergeben sich für den config-Mode?		# Wollen wir im Config-Mode Internet bereitstellen um eine Kartenposition zu suchen (afair nicht in gluon). Welche Konsequenzen ergeben sich für den config-Mode?
	# Welche Informationen stellen wir da (-> Chat, Nodekontakt, etc.). Wie sollen Benutzer sie finden?		# Welche Informationen stellen wir da (-> Chat, Nodekontakt, etc.). Wie sollen Benutzer sie finden?
	# Wo legen wir die Informationen ab? Alfred, MySQL-Datenbank? NoSQL-Datenbank, clustered auf Supernodes...		# Wo legen wir die Informationen ab? Alfred, MySQL-Datenbank? NoSQL-Datenbank, clustered auf Supernodes...
	# Verhältnis zum Raketenkontrollzentrum		# Verhältnis zum Raketenkontrollzentrum
	** Existieren beide Parallel?		## Existieren beide Parallel?
	**Wird eins in das andere eingebettet?		## Wird eins in das andere eingebettet?
	** Schnittstellen?		## Schnittstellen?

	Ich hab' hierzu keine feste Meinung und bislang auch wenig überzeugende Argumente / Ideen gehört.		Ich hab' hierzu keine feste Meinung und bislang auch wenig überzeugende Argumente / Ideen gehört.
Zeile 36:		Zeile 36:

	Aus den letzten beiden Thesen kommen ein paar Punkte:		Aus den letzten beiden Thesen kommen ein paar Punkte:
	* Warum machen Node-Aufsteller falsche Angaben / nutzen nicht-funktionierende E-Mail Adressen als Kontaktadresse in register?		# Warum machen Node-Aufsteller falsche Angaben / nutzen nicht-funktionierende E-Mail Adressen als Kontaktadresse in register?
	** These: Sie wollen nichts über Probleme hören oder haben kein Interesse an der Kontaktaufnahme mit Nutzern		## These: Sie wollen nichts über Probleme hören oder haben kein Interesse an der Kontaktaufnahme mit Nutzern
	** These: Register ist ein "Telefonbuch" wo zu einem Node eine Kontaktmöglichkeit hinterlegt wird. Register ist sinnlos, wenn es falsche Kontaktadressen beinhaltet. Die gibt es, also ist register sinnlos.		## These: Register ist ein "Telefonbuch" wo zu einem Node eine Kontaktmöglichkeit hinterlegt wird. Register ist sinnlos, wenn es falsche Kontaktadressen beinhaltet. Die gibt es, also ist register sinnlos.


	=== Neue Firmware-Releases / Folgen des Gluon / LFF upstreams ===		=== Neue Firmware-Releases / Folgen des Gluon / LFF upstreams ===
	# Welche Software-Pakete / Features wollen wir aus gluon nutzen?		# Welche Software-Pakete / Features wollen wir aus gluon nutzen?
	** Zur Zeit verwenden wir bspw. nicht das batman-adv-Paket, da es mit der Visualisierung Probleme gab - gibt?		## Zur Zeit verwenden wir bspw. nicht das batman-adv-Paket, da es mit der Visualisierung Probleme gab - gibt?
	** Den autoupdate wohl nicht		## Den autoupdate wohl nicht
	** config-mode / expert mode wikt eher schwer		## config-mode / expert mode wikt eher schwer
	** Build-Prozess site-file: Eher nicht, schränkt den build stark ein		## Build-Prozess site-file: Eher nicht, schränkt den build stark ein
	# Wie weit wollen wir uns konzeptionell an gluon annähern, bzw. gluon an un?		# Wie weit wollen wir uns konzeptionell an gluon annähern, bzw. gluon an un?
	** Unterstützen wir Christof bei dem Ansatz, collectd und auto-key-upload in "gluon aufzunehmen"?		## Unterstützen wir Christof bei dem Ansatz, collectd und auto-key-upload in "gluon aufzunehmen"?
	** Was bedeutet "aufnehmen" eigentlich an der Stelle?		## Was bedeutet "aufnehmen" eigentlich an der Stelle?
	# Was stört uns an Gluon?		# Was stört uns an Gluon?

Zeile 69:		Zeile 69:
	=== Sonstiges ===		=== Sonstiges ===
	# QoS:		# QoS:
	** Wie verhindern wir, dass eine Überlast-Situation das Netzwerk hart trifft?		## Wie verhindern wir, dass eine Überlast-Situation das Netzwerk hart trifft?
	** Wer hat Erfahrung mit QoS. Evtl. macht Jan dazu mal eine Session mit PEra		## Wer hat Erfahrung mit QoS. Evtl. macht Jan dazu mal eine Session mit PEra
	# FFFM: Was hat Christof für Pläne und Visionen		# FFFM: Was hat Christof für Pläne und Visionen

Benutzer:Yanosz:Ideen - Versionsgeschichte

Yanosz am 28. November 2014 um 15:28 Uhr

Yanosz: Die Seite wurde neu angelegt: „== Einleitung == Der 31c3 steht vor der Tür und damit die Chance mit Freifunkern Ideen und Erfahrungen auszutauschen. Gleichzeitig sind wir mit der Umsetzung…“