una pregunta que se m'acudeix carles ...

el teu model de dades i de codi es podria posar al drupal sense haver de refer-ho de pe a pa per adaptar-lo al motlle del drupal?

perquè el que no veig viable és haver de tornar a fer-ho tot des del principi aquí al drupal

per la resta, doncs si, el teu model de dades i la orientació que li has donat a tot plegat ja es molt extensible i ampliable

que faria guifi sense vosaltres!!!

Si que es podria fer, però amb algunes consideracions.

1. El model de dades hauria de ser igual o molt semblant al que he fet.
2. Caldria adaptar el sistema de permisos al drupal, al Plone o a qualsevol altre gestor de continguts
   Seria interessant fer una classe d'adaptació als diferents sistemes de gestió que permetés utilitzar diferents sistemes de permisos. Així segur que el codi seria independent del gestor de continguts.
3. Adaptar la descripció de les pàgines/nodes als diferents gestors de continguts.
   Amb el Mediawiki, la descripció està en la pròpia pàgina del gestor de continguts.
4. Adaptar el sistema d'URL als diferents gestors de continguts.
   El drupal funciona diferent del MediaWiki amb les URL.
5. Adaptar el sistema de logs als diferents gestors de continguts.
   Encara no està implementat, però seria interessant per registrar les configuracions antigues, i veure qui ha fet què i quan.
6. Caldria adaptar el sistema de themes a cada sistema.
   Ara mateix no existeix

Salut !!!
Carles

En el diagrama de dalt a la dreta hi ha una respresentació gràfica general de les taules més importants del model de dades. S'hi pot observar l'aparició de la nova taula d'adreces penjant de la de connectors. Més en concret els canvis a implementar serien:

• A nivell global, afegir un identificador únic de servidor.

Sembla lògic.

• A nivell de zona, afegir un atribut de zona pròpia, o importada, especificant en aquest cas l'identificador de quin servidor, la url d'importació i cada quan es refresca.

Com ja he comentat, el sistema que he desenvolupat, ja preveu això de forma més genèrica, i sense haver de canviar el model de dades. Només caldria ficar una limitació per impedir afegir nodes manualment. Jo en aquest cas obviaria importar dispositius i sub-xarxes.

• A nivell de localització, s'hereda la zona ospf de la zona, però es permet de posar-ne una altra. Aquest atribut es va heredant en les successives entitats fins a arrivar a la ipv4.

Per descomptat, l'objecte zona s'ha d'utilitzar per a que els dispositius n'obtinguin les dades necessàries per configurar-se que han de ser comuns a tota la zona, com són els rangs d'IP's, l'àrea OSPF, ... També serà qui ha d'assignar una xarxa a un dispositiu o node. En aquest enllaç podeu veure com s'assignen les Ip's a una interfície, ja siguin pròpies, públiques o troncals.

• A nivell de connector, ara només son de tipus Lan, Wan (per als cables), wLan (per a les conexions sense fils) i tunels i bridges per a les virtuals. Les de tipus bridge relacionen les interfícies entre si (una possible nova entitat?...).

Per descriure't per sobre com funciona els tipus d'enllaços en el meu desenvolupament, et puc dir que totes les interfícies són factibles d'enllaçar, però amb algunes restriccions. Aquestes restriccions són a diferents nivells (zona, node, dispositiu, adaptador, interfície). Així abans de permetre un enllaç, es pregunta a la zona amb quins nodes es pot realitzar, al node se li pregunta si es pot fer la connexió (una possible limitació seria la distància, ...), passant per si els dispositius són compatibles, els adaptador poden connectar-se (difícilment poden connectar-se un RJ45 i una antena Wifi, o dues antenes de 6dB a 15km tampoc es podrien connectar), tot això amb restriccions de diferents nivells (usuari, administrador, super-administrador). I per acabar a nivell d'interfície, només es poden connectar dues interfícies, una amb IP i l'altra que li'n demanarà una altra (sempre que n'hi quedin lliures). Així també s'obliga a mutu acord entre ambdós nodes per realitzar l'enllaç.

En aquest enllaç, a l'apartat de links podeu veure els possibles enllaços que es poden fer i les limitacions que hi ha quan se selecciona un possible enllaç. El node "TonaXarli" disposa d'una interfície disponible per fer l'enllaç, les altres NO. Veureu que el botó de crear l'enllaç no s'activa fins que l'enllaç és possible, i si no es possible n'indica el motiu.

• A nivell de ipv4, tantes adreces com es vulguin per cada connector.

Per descomptat, jo ho he sol·lucionat amb tenir tantes interfícies com es vulgui per a cada port. L'únic que em causa problemes són els ponts, però adaptables a la BD.

• Les ràdios han de suportar atributs propis de 5GHz. Potser convé especificar la freqüencia en MHz.

Crec que marejareu la perdiu si ho feu d'aquesta manera. Crec que la forma en que ho he implementat jo és més elegant, i flexible. Com podeu veure, en el meu desenvolupament són els adaptadors els que contenen aquests tipus d'atributs i ells disposen de funcions que indiquen si es pot realitzar un enllaç amb un altre adaptador. El fet d'utilitzar diferents freqüències pot ser un paràmetre o un altre tipus d'adaptador.

• La idea és questa vegada fer-lo via comnmits a la SVN. Es corre el risc de introduir alguna inestabilitat, però al menys no hi hauria un trencament total i es pot abordar de forma més incremental.

El sistema que he desenvolupat, és molt modular i permet que la gent desenvolupi mòduls sense interferir en el nucli dur de l'aplicació. Potser a mida que es vulguin afegir millores calgui fer alguns canvis al nucli (ja en tinc alguns que s'hauran de fer), però per fer això s'ha de consensuar per no trenca la modul·laritat.

Espero que us interessi.

Carles

M'havia oblidat de dir quatre avantatges més que ja estan desenvolupats.

1. Geo-referenciació amb GPS
   Com per exemple amb el mapa del planeta que en aquesta pàgina en l'apartat de GpsRef podeu veure com es geo-referencia, tenint una calculadora per transformar diferents tipus de coordenades, i poden desplaçar el cursor pels diferents punts per editar-los o esborrar-los.
2. Desenvolupament de Plug-in's
   Com podeu veure en les zones (anoia.guifi.net/proves/Zona:Tona) i els nodes (anoia.guifi.net/proves?title=Node:TonaMancomunitat&action=edit), al costat del mapa hi ha una sèrie d'opcions que fan diferents coses.
   Des de mostar els nodes de la zona, els enllaços, els límits, fins a funcions específiques de configuració, així es poden desenvolupar plug-in's per a tothom o específics per als administradors.
   Tingueu en compte que des de la càrrega del mapa, fins a la gestió de xarxes i la geo-referenciació es realitza mitjançant plug-in's que carreguen les dades que els interessa.
3. Alguns exemples de plug-in's interessants
   - Mirant la funcionalitat que tenim ara, podem pensar a realitzar un plug-in que visualitzi un perfil entre dos punts qualsevol del mapa, o des de dos nodes (els plug-in's podeu fer ús de la funcionalitat dels mapes).
   - També seria factible un plug-in per veure la disponibilitat dels enllaços.
   - Una altra cosa interessant seria un mapa de contaminació de freqüències.
   - O un mapa de amples de banda dels enllaços.
   - I tot això sense modificar cap codi existent.
   - Algú té més idees?

Salut !!!
Carles

Carles, toquem de peus a terra: El que t'estàs currant és una nova aplicació. Sencera.
Si ho soluciona tot o no, si els usuaris la troven més fàcil o no, si dona tota la funcionalitat o no, es veurà posant-la en marxa.
I això està per veure: No és fàcil fer una aplicació sencera nova trencant amb el que hi ha, tant de bó el sistema del nodeXchange facliti aquesta engegada.
No confonguem entre el que tenim funcionant, les millores que suggerim sobre l'actual, i noves aplicacions. Fem el que ens vingui de gust però no barrejem coses, perquè sino ens liarem i ens bloquejarem.
Jo en aquesta millora de disseny només m'adreço a millorar l'aplicació actual.

Sobre les entitats que proposes en els teus diagrames tinc alguns dubtes: Sobre la conveniència de crear una entotat per les àrees, i el significat de ports/adaptors/ifaces vs devices/infaces/ips. Els plantejo a la llista.

Ja toco de peus a terra. I el que he desenvolupat no és una nova aplicació, sinó una adaptació del que hi ha ara per a que sigui més flexible, tal com vols fer en la nova versió.

Jo m'he limitat a fer-vos veure que el que estàs demanant per a la nova versió és el que he fet.
- Simplificar el codi i comentar-lo. FET
- Major flexibilitat per als tipus de connectors (interfaces). FET
- Major flexibilitat per al suport de dispositius de diferents tipologies (p.ex. LinuxAP,Mikrotik...). FET
- Implementació compplerta del RouterOS a l'unsolclic. FACTIBLE
- Suport per a la definicio de limits de zones (ABR). FET
- Preparar el model de dades per la sincronització via nodeXchange entre servidors diferents. FACTIBLE
- Prepapar un futur suport a ipv6. FACTIBLE

I per a concretar més:
- A nivell de zona, afegir un atribut de zona pròpia, o importada, especificant en aquest cas l'identificador de quin servidor, la url d'importació i cada quan es refresca. FET
- A nivell de localització, s'hereda la zona ospf de la zona, però es permet de posar-ne una altra. Aquest atribut es va heredant en les successives entitats fins a arrivar a la ipv4. FET
- A nivell de connector, ara només son de tipus Lan, Wan (per als cables), wLan (per a les conexions sense fils) i tunels i bridges per a les virtuals. Les de tipus bridge relacionen les interfícies entre si (una possible nova entitat?...). FET
- A nivell de ipv4, tantes adreces com es vulguin per cada connector. FET
- Les ràdios han de suportar atributs propis de 5GHz. Potser convé especificar la freqüència en MHz. FET

Ara m'expliques quines diferències hi veus, i si és una nova aplicació o una adaptació ben feta. El meu desenvolupament és una proposta d'adaptació del que hi ha ara per millorar-ne futurs canvis i desenvolupaments.

Ens veiem a la llista.

... per ser una adpatació, hauria de fer-se via pegats, incloent la migració.
Un branch s'ha d'arrencar. I per arrencar-lo totes les caselles haurien d'aparèixer com a FET.
Mentrestant és un projecte de branch

Com pots veure en aquest enllaç.

Per finalitzar la migració caldria treure les inconsistències de la BD. Però ja en vam parlar i no consideraves que existissin tals inconsistències.

Tranquil, ja tinc al cap com treure aquestes inconsistències durant la migració.

falta completar-ho...
a més per posar-ho en marxa adona't que caldrà com a mínim fer anar nodeXport de forma bidireccional, com a mínim fins que no descartem el que el que hi ha.
sobre les inconsistències, si et refereixes a adreces o links orfes, efectivament es poden obviar. En resum, el que crec que fa l'script d'en lasker.