[ffda] Changelog 0.8.0

[francismb]

Servus psy,

>> --> ODER bei gleicher Anzahl an FFDA-Router-Peers dann Router wählt
>> Kanal mit am wenigstens nicht FFDA-Router-Peers
>> (Priorität: "For Performance!")
> Und genau hier hast du dann das Problem, dass der neue Router einer von
> beiden Meshwolken beitritt und nicht beide verbindet, was du eigentlich
> willst. Du opferst also das Mesh für einen evtl ein bisschen besseren
> Kanal. Dann können wir das Mesh auch gleich bleiben lassen und Hotspots
> anbieten. IMHO nicht das, was wir anstreben.
>>
>>>> Das ganze müsste jedes Mal aufs neue geschehen, wenn
>>>> ein Router dem Mesh beitreten will (oder das Mesh verlässt). 
>> Sehe ich nicht warum (? Goto 3 ... ?)
> Weil sonst das passiert, was du unter C beschreibst und/oder die
> Kanalauswahl nicht mehr optimal ist. Dann kann man sich das auch sparen.
> 
"Kill Komplexität" könnte auch eine Rahmenbedingung sein :-)

> Insgesamt trägt das was du gerade skizziert hast nicht zu einer
> tatsächlichen Kanalauswahl bei, da immer der erste Router bestimmt,
> welcher Kanal optimal ist und die Auswahl daher immer aus seiner Sicht
> passiert. Diese Auswahl muss aber für andere Router nicht gleich sein,
> auch wenn sie in seiner Nähe sind. Dennoch würden sie nach deinem Model
> seiner Auswahl folgen.
> 
> Du siehst: Nicht so einfach ;-)
> 
Ich hatte dir ja recht gegeben :-), wollte etwas "Simulated Anneling"
ins spiel bringen und der Gedanke eines nicht "Full-Conected-Graphs" in
die Runde werfen. Die meisten Nodes stehen allein oder nicht verbunden
da, so glaube ich in diesem Fall performance gewollt.

Hat jemand die Liste: "Number-of-Peers: Count" gemacht?


Und klar es fehlen Rahmen Bedingungen (Prioritäten) bzw. sind nicht
definiert, aber interessant.

Danke für den Austausch!

Saludos,
francis