Me parece muy buena idea modulizar el proyecto. Mañana me pongo con ello. Lo unico que no entiendo muy bien eso de un consumidor de cámaras... en cuanto me lo cuentes empiezo. jejejjeje

Mañana tambien mirare y empezare el EQAScope. Si lo veis bien.



El día 5/12/07, Antonio Fraga <antoniofga@yahoo.es> escribió:
Y yo que pensaba que ASCOM estaba "en coma"...
http://download.ascom-standards.org/ASCOMPlatform5Beta2.msi
 
, con templates en .NET2005 para crear nuevos drivers de cámara, de telescopio, etc.
 
Bien, me pondré a trabajar en un componente consumidor para EQACam. Samuel, si montamos un consumidor de cámaras ASCOM para EQACam, la QHY5 estaría soportada automáticamente. Otra cosa es que además implementemos los componentes ASCOM para las Atik, webcam SC1, QHY6 o las que sean, que también lo podríamos hacer así y otra cosa es un componente de soporte directo en EQACam.
 
Creo que también habría que rediseñar todo el sistema de telescopios de la misma manera: Por una parte un consumidor puente hacia ASCOM, como hasta ahora, además implementar soporte directo a LX200 (con los comandos basicos) y que todo ello esté en una librería separada EQAScope.
 
Así el proyecto EQAlign sería el conjunto de:
 
- Ephemerids y a través de ephemerids de elp82 (Luna) y series96 (planetas) Estos proyectos los podemos considerar ahora como release. Por seguir la nomenclatura podría pasarse a llamar EQAEphem.
- EQACam como servicio de acceso a cámaras, con poco más ya lo tenemos.
- EQAScope como servicio de acceso a telescopios, es mucho más sencillo que EQACam, es sólo un puente hacia ASCOM y poco más
 
Por ahora podríamos dejar todo lo demás en EQAlign o considerar:
 
- EQAProjection como servidor de proyecciones. Aquí me gustaría que trabajaras tú Andrés, en cuanto te des-líes.
- EQACalc como módulo de cálculos de alineado, autoguiado, con todos los módulos cálculo de centroides, mediciones, etc... Aquí sólo hay que trabajar en mejorar el autoguiado, el resto lo considero estable y utilizable.
 
Todos ellos planteados como librerías de servicio y el proyecto EQALign que nos sería ya sino "costura e hilo", el interfaz de usuario. Aquí deberíamos reconsiderar el modo en que construimos los controles de usuario, por ejemplo unificar el actual UCCamera (que se repite en cada control de proceso -calibrado, alineado, autoguiado y medición de error periódico-) y que todos los procesos utilicen el mismo (parece lo lógico).
 
De esta manera dividimos el proyecto en módulos más especializados, la interoperatibilidad está clara, la más difícil es unificar los autoguiadores de telescopios, cámaras y relay box, pero no lo veo complicado, basta que cada cámara que soporte ST4, implemente además un interfaz específico de autoguiado, todos los telescopios ´(todos son DA1, LX200 directo y ASCOM) lo implementarán también (además del propio de telescopio) y los dispositivos específicos (SHoestring y demás) sólo implementarían este interfaz. Así, en lugar de separar telescopio y autoguiador de telescopio (como hasta ahora) o cámaras y el autoguiador de la cámara, estaríamos viendo la misma clase con otro disfraz.
 
Creo que no es mucho trabajo, lo tenemos casi todo hecho. Yo crearía otra rama y organizáría el repositorio SVN (no conozco mucho SVN y no sé cómo borrar proyectos) Esa es mi propuesta.
 
Un saludo

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Eqalign-devel mailing list
Eqalign-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/eqalign-devel