Cliente/servidor Wi-Fi de Linea 8

Estudio de viabilidad Linux del Cliente/servidor Wi-Fi de Linea 8

• Reamente bastaría con el autozoom actual para que fuera usable par una persona razonablemente experimentada.
• Es muy necesario implementar reconexiones tanto en tclient como en prusdlconnect para que cuando se puede la cobertura no se vaya al login (puede llegar a ser molesto). La única cosa a decidir es qué hacer si se pierde la conexión contra tcii-server. Una manera razonable sería "avisar" a prusdlconnect y hacer reintentos de conexión (el avisar sería decirle a prusdlconnect que se desconectase mientras no tengamos un enlace con tcii-server).
• Hay que buscar una manera de hacer zoom de forma que se ocupe toda la pantalla con el plano. Hay que buscar la manera de pasar de 1024x768 a 640x480 (hay que coger convertir 1.6 píxeles a 1; si lo hago con 1.5 sería 960x720, lo cual se acerca bastante al tamaño del plano).
• El interfaz de salidas de emergencia se sale de la pantalla

En f_ui_plano/OrdenesEstacion.Remoto.c hay un "case SET_ESTACION" en el que se procesa el mensaje que se tendria que mandar al ui_plano_remoto.

Hay que formatear un mensaje de SET_ESTACION con

sscanf( sTexto, "%02d%02d%d %d %x %[^\n]", &linea, &estacion, &vestibulo, &TipoNodo, &IdUnivoco, Parametros )

Siendo TipoNodo==TN_PCL (bueno, eso habría que comprobarlo).

En el ui_operador_new se compone esta orden. Habría que usar ago parecido de lo que se hace ahí.

Si no importa el nombre que aparece en la ventana, entonces se puede hacer simplemente quitando los liks siguientes y volviéndolos a crear pero en la nueva estación:

==CUT===

demo@FrontPCI02:~/sistema/V/UI_Plano/ui_plano00$ ls -l | grep Fich| grep Estacion
lrwxr-xr-x 1 demo demo 23 Oct 6 09:32 FichIconosEstacion -> ../../Comun/10191.icons
lrwxr-xr-x 1 demo demo 24 Oct 6 09:32 FichPlanoEstacion -> ../../Comun/10191.Raster
lrwxr-xr-x 1 demo demo 24 Oct 6 09:32 FichTextosEstacion -> ../../Comun/10191.Textos

==CUT===

Otra manera es mirando la callback del menú de las estaciones (y habría que comprobar cómo lo hace exactamente, ya que en principio hace alguna comprobación adicional con algún timer/fecha que no está expuesta aquí):

1. Deshace los enlaces
2. Hace los nuevos
3. Escribe un fichero que mirará la siguiente vez que arranque y hará que se ponga como "de la nueva estación"
4. se sale con un exit para que control le vuelva a rrancar

Explicaciones gentileza de Rosa

Actually, IrLPT is the same as IrCOMM 3 wire raw, but [there] is no obligation for IrCOMM to implement 3 wire raw. IrCOMM is a collection of 4 protocols: 3 wire raw, 3 wire "cooked", 9 wire and centronics, but the standard don't make any of them mandatory. The only responsibility of an implementation is to advertise that is implemented.

What GNOME has been talking about is a clipboard manager using the same basic protocol as xclipboard and Motif's clipboard. That is a program that claims the manager selection CLIPBOARD_MANAGER and the selection CLIPBOARD. When it loses the CLIPBOARD selection, it requests data from the new owner, and upon receipt of that data it reclaims the CLIPBOARD selection. Through loss and reclamation of the CLIPBOARD selection, it knows when new clipboard data is available.

1. Localizamos al gestor de zooms usando un método análogo al del clipboard (preguntando por el owner del AUTOZOOM_MANAGER)
2. La aplicación manda un mensaje de tipo "AUTOZOOM_OPCODE" tal y como se explica aquí cada vez que se muestra u oculta, que contiene como parámetros una bandera que indica si está mapeado o no, sus dimensiones y posición.

+-----+
| XXX |
| XXX |                             +----------------------------+
| XXX |                             |                  +-------+ |
|  _  |                             |  []        o o o +-------+ |
+-----+                             +----------------------------+
 PDA:                                TCIISERVER:
 * prusdlconnect                     * pnt_server 0
 * tcii_client                       * pnt_server 1
 * camera_ig                         * tcii_master
                                     * control+apps
                                     * isacd
                                     * crptcii

         PDA1                   TciiServer              PDA2
         ----                   ----------              ----
 ,-------------.            ,------------....
 |prusdlconnect+------------+pnt_server 0|  :
 `-----------+-'            `------------'  :
             |              ,------------....           ,-------------.
             |              |pnt_server 1+--------------+prusdlconnect|
             |              `------------'  :           `-+-----------'
         ,---+-------.      ,-----------.   :      ,------+----.
         |tcii_client+------+tcii_master+----------+tcii_client|
         `-+---------'      `-+---------'   :      `---------+-'
           |                  |  ,------------.              |
  ,--------+.                 |  |control+apps|             ,+--------.
  |camera_ig|                 |  `-----+------'             |camera_ig|
  `---------'                 |     ,--+--.                 `---------'
                              |     |isacd|
                              |     `--+--'
                             ,+------. |
                             |crptcii+-'
                             `-------'

1. Mostrarlo en el pda adecuado: saber qué aplicación(UI en qué display) ha mandado la petición. El isacd sabe qué aplicación ha sido, y se podría tener una tabla que relaciona el numero de aplicación con el display.
2. Que si otro PDA tiene fijada esa cámara, no le valga a la apli si no está en su "posición de la matriz": ya que si no, validaría siempre como que se ha podido mostrar la cámara cuando en realidad la está mostrando otro PDA.

• cambiar la librería de LisIsaCD.c para que admita múltiples instancias.
• hacer que las aplics (UIs) usen una variable de configuración de DIR_ISA_DATOS en vez de la variable de entorno del mimo nombre (lo usan para saber el directorio donde el isacd guarda el estado.retros).

• DW:XSLT desde python
• Listado de tutoriales WSDL en troobloo

• Habíamos quedado en que íbamos a usar las X.
• Para el proyecto "futuro" necesitamos usar las X. No nos va a ser fácil controlar todo esto desde Qt/Embedded y no podemos contar con ello.
• Nosostros estamos usando SDL por lo que podemos trabajar bajo Qt/Embedded, pero habrá que ver cómo hacemos para hacer la gestión de poner delante la otra apli, etc.
• Si quieren usar Qt, deberían usar las Qt completas,que son las que funcionan bajo X.

• Venta
  • mettas: consultar estado, contadores, averías.
• Peaje
  • portón: abrir
  • pupitre: ver contadores, ver estado, cambiar estado
• Accesos
  • cancelas: consultar estado, abrir, cerrar
• Control de Instalaciones
  • escaleras (req. integración vídeo): ver estado, arrancar, parar
  • ascensores: ver posición, poner fuera de servicio
  • ventiladores de túnel: arrancar, parar
  • ventiladores de anden: arrancar, parar
  • luz de túnel: ves estado, encender, apagar
  • cámaras: (req. integración vídeo): visualizar
  • megafonía: mensajes pregrabados
• Teleindicadores
  • carteles teleindicadores: ver mensajes, ver previsión de tiempos de llegada de trenes.
• PCI
  • detección: visualización del nivel de humos
  • extinción: control de la centralita de extincion y actuación sobre las electroválvulas de extinción.

Descripción del proyecto

• @Introducción

Introducción

• con el plano+drivers cargados, igual que si fueran una op.
• con un programa que sirva la "pantalla" a los elementos remotos
  • hay que ver alguna manera de hacer el equilibrado de carga entre varios servidores
  • tiene que servir la pantalla por un medio seguro (ssh?) y que no se puedan conectar a él los que no pertenezcan a este sistema (p.ej. evitando a toda costa tener abierto un puerto VNC estándar al mundo).
  • tiene que ser lo más abierto posible (p.ej. de código y soporte al protocolo) y que realice su tarea de manera "invisible" (es una parte que no interesa al operador).

• aplicación que permite conectarse a los servidores de pantallas
  • que tenga unos mandos en pantalla similares a los del tarantella.
  • que la comunicación establecida sea "segura"
  • código realizado en SICO si es posible.