<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/09/2014 08:15 PM, Clauz wrote:<br>
</div>
<br>
[CUT]<br>
<br>
<blockquote cite="mid:545FBD54.6070504@ninux.org" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">- a parte i collegamenti su cavo, temo che i costi sui link
wireless potrebbero cambiare in continuazione, e quindi ogni volta
il diff per una rete prevalentemente wireless sarebbe quasi tutta
la rete (rendendo vano il diff). Forse avrebbe senso calcolare il
diff sulla topologia assumendo tutti i link con costo pari a 1, e
gestire poi i costi sui link con un'API separata?
</pre>
</blockquote>
<pre wrap="">
Scorporare questa parte per poi sostanzialmente fare la stessa cosa
(query nel db) non credo abbia troppo senso. Se il peso dell'arco
rimane nel db credo che questa sia la soluzione più veloce.
Potremmo,però , arrotondare tutto alla parte intera, e fare il diff
con quello. Così lo inseriamo nel db solo quando cambia sensibilmente.
</pre>
</blockquote>
<pre wrap="">
Forse si potrebbe pensare a chiamate (o callback, etc) diverse dell'API:
- chiamata che ritorna diff nella topologia comprese tutte le minime
variazioni di costo sui link
- chiamata che ritorna diff nella topologia come se tutti i link
avessero peso 1
- chiamata che ritorna diff nella topologia quando il costo sui link
supera un certo delta passato come parametro
- chiamata che ritorna tutta la topologia corrente (quindi NON il
diff), inclusi i costi
Clauz
</pre>
</blockquote>
<br>
Cominciamo col caso più semplice da realizzare e poi aggiungiamo
nuove feature una alla volta.<br>
<br>
Ho creato il pacchetto python installabile:<br>
<a class="moz-txt-link-freetext" href="https://github.com/ninuxorg/netdiff">https://github.com/ninuxorg/netdiff</a><br>
<br>
Leggete il README, è minimale ma ci sono scritte le cose essenziali
per poter collaborare.<br>
<br>
Ho utilizzato il nome netdiff perchè mi sembrava appropiato, se una
volta che avremo le idee più chiare vorremo cambiarlo potremo farlo.<br>
<br>
Ho preso il codice di Gabriel e l'ho semplificato e c'ho scritto un
test:<br>
<a class="moz-txt-link-freetext" href="https://github.com/ninuxorg/netdiff/blob/master/tests/olsr1/tests.py#L14">https://github.com/ninuxorg/netdiff/blob/master/tests/olsr1/tests.py#L14</a><br>
<br>
Il test dovrebbe assicurarsi che nulla è cambiato (perchè gli ho
passato la stessa topologia come old e come new) ma non conoscendo
la libreria non so quale metodo usare, credo sia edges() ma
preferisco verificare con calma o lasciare che qualcuno di voi
faccia modifiche.<br>
<br>
Ecco alcune semplici domande per poter procedere:<br>
<ul>
<li>@Gabriel, hai un account su github in modo che posso
abilitarti a fare commit sul repo?<br>
<br>
</li>
<li>Servono alcuni esempi di topologie OLSR1 semplici su cui
scrivere gli unit test, quella che ho scaricato dall'esempio
iniziale di Gabriel (salvata qui:
<a class="moz-txt-link-freetext" href="https://github.com/ninuxorg/netdiff/blob/master/tests/olsr1/topology1.json">https://github.com/ninuxorg/netdiff/blob/master/tests/olsr1/topology1.json</a>)
è troppo cicciotta per poterci lavorare in modo agile; qualche
idea di come recuperarli?<br>
<br>
</li>
<li>@Clauz: per quanto riguarda tutte le feature del vecchio
parser, hai una vaga idea di come potremo riportarle su questo
nuovo? Ho paura che alcune cose saranno toste perchè forse lo
script che sta dentro nodeshot 0.9 fa molte cose specifiche per
noi... o sbaglio? Spero di sbagliarmi ... :D<br>
</li>
</ul>
<p>Ricordiamoci che l'idea che abbiamo oggi è vaga e avrà bisogno di
molti miglioramenti e cambiamenti.. cerchiamo la soluzione
migliore che ci assicuri questi obiettivi:<br>
</p>
<ul>
<li>disaccoppiare il codice che capisce i cambiamenti della
topologia da quello dell'applicazione web<br>
<br>
</li>
<li>fare in modo che chi non ha conoscenze di django e nodeshot
possa comunque contribuire alla parte che gestisce la topologia<br>
<br>
</li>
<li>adottare la filosofia unix di fare una modulo che fa una cosa
ma la fa bene<br>
<br>
</li>
<li>supportare più protocolli di routing, l'ideale sarebbe
iniziare con Olsr1 e batman-adv<br>
<br>
</li>
<li>fare in modo che questo modulo sia riutilizzabile anche da
altre community<br>
<br>
</li>
<li>scrivere una documentazione chiara e semplice<br>
</li>
</ul>
<p>Se riusciamo a fare queste cose avremo fatto qualcosa di utile e
duraturo, oltre che aver imparato un sacco di cose.<br>
<br>
E soprattutto spero che riusciremo a lavorarci insieme, evitando
che tutta la conoscenza sia centralizzata su di me.<br>
</p>
<p>Bella!<br>
Nemesis<br>
</p>
</body>
</html>