Controller, GlobalDatastore e file

Questa pagina descrive ciò che esce dallo schema « moduli → proprietà → elementi » delle pagine precedenti: i dati del controller, il modulo centrale GlobalDatastore e il file system del server. Un client che si limita a mostrare i moduli non ne ha bisogno; un client che vuole offrire ciò che propone una pagina di parametri globali (configurazioni, driver INDI, carico del server, attrezzatura, immagini) deve gestirli.

I dati del controller (controllerdata)

Il controller è il componente del server che carica i moduli e pilota il server INDI integrato. Espone i propri dati nel dump, sotto la chiave controllerdata (vedi d), poi li mantiene aggiornati con messaggi uc.

systemwatcher: carico del server

Il server misura il proprio carico a intervalli regolari e lo diffonde a tutti i client. L’intervallo si regola con l’opzione --systemwatchinterval (secondi, 10 per impostazione predefinita, 0 disattiva). Il messaggio è un normale uc, e l’ultimo valore è presente anche in controllerdata.systemwatcher del dump.

{
  "uc-update controller data": {
    "systemwatcher": {
      "cpu": { "load_1m": 10.42, "load_5m": 9.79, "load_15m": 4.51 },
      "ram": { "used_mb": 12194, "total_mb": 31941 },
      "disks": [
        { "device": "/dev/nvme0n1p2", "mountpoint": "/", "used_gb": 789.4, "total_gb": 915.3 }
      ],
      "network": [
        { "iface": "enp4s0", "rx_kbps": 16.27, "tx_kbps": 448.8 }
      ],
      "temperatures": [
        { "type": "Tctl", "temp_c": 75.375 }
      ]
    }
  }
}

Configurazioni e ciclo di vita dei moduli

Una configurazione è un insieme denominato di moduli (libreria, etichetta, profilo) che il server può ricaricare in un colpo solo. L’elenco si trova in controllerdata.availableconfs, la configurazione attiva in controllerdata.currentconf.

I moduli effettivamente caricati sono quelli del dump (d.m); compaiono e scompaiono tramite aa e dm. La configurazione non contiene mai GlobalDatastore (vedi sotto), che è sempre presente.

Server INDI e driver

Se controllerdata.indiserver vale "Y", il server pilota un’istanza INDI integrata. I comandi YA/YZ/YL/YR/YS la avviano, la arrestano e gestiscono i driver; controllerdata.indidrivers fornisce il catalogo disponibile e controllerdata.indiactivedrivers ciò che è in esecuzione. binary è il valore da passare come driver in YL, YR e YS.

Il modulo GlobalDatastore

GlobalDatastore è un modulo come gli altri nel dump (d.m.GlobalDatastore, con proprietà, elementi, griglie, profili), ma il suo ruolo è centrale:

• è creato dal server prima di tutti gli altri moduli ed è sempre presente: MK su di esso viene rifiutato, e non è mai incluso in una configurazione;
• contiene il riferimento condiviso dell’attrezzatura, che tutti gli altri moduli consultano: ottiche, località, attrezzature (set di dispositivi) e server INDI.

Le sue griglie servono da sorgente per elenchi di scelta (LOV) con lo stesso nome, presenti in d.lovs (optics, locations, equipments, servers) e ricostruiti a ogni modifica della griglia. Gli altri moduli le usano così: scegliere un’ottica compila la focale e il diametro, scegliere una località compila latitudine, longitudine e altitudine, scegliere un set di attrezzature risolve i dispositivi (camera, montatura, focheggiatore, ruota portafiltri, camera di guida, GPS, cupola, meteo) e il server INDI da contattare.

Proprietà esposte:

Tutte le sue proprietà si manipolano con i messaggi standard (SV, SA, GC…, I3/I4 su locations); un client generico le mostra come qualsiasi altro modulo. Rooster le presenta in una scheda dedicata della sua pagina di parametri, mantenendo le proprietà che hanno un profilo (hasprofile) e raggruppandole per level1/level2.

File system

Il server pubblica l’elenco dei file prodotti (immagini, sequenze, archivi) nella cartella --webroot, senza che il client debba interrogarlo. Questo meccanismo è indipendente dai moduli.

Nel dump: d.files

"files": {
  "folders": ["", "/Allsky", "/Sequencer/gam Cyg/LIGHT/Luminance"],
  "files": ["/image1.jpeg", "/rapport.txt"],
  "selectedfolder": "/home/gilles/ostmedia"
}

Non ci sono né paginazione né limite di dimensione: su un webroot molto pieno l’elenco può essere lungo.

Scegliere la cartella: FS

FS indica la cartella di cui si vuole l’elenco dei file. Il server sorveglia una sola cartella alla volta.

Aggiornamenti: evt

Quando il contenuto della cartella selezionata cambia (file creato, eliminato o rinominato), o dopo un FS, il server invia eventi di primo livello evt:

{ "evt": "fileadd", "fileevent": ["/Sequencer/gam Cyg/LIGHT/Luminance/img_001.FITS"] }
{ "evt": "filedel", "fileevent": ["/rapport.txt"] }

fileevent è sempre un array; oggi contiene un solo percorso per messaggio (N file = N messaggi). Dopo un FS, il client riceve un filedel per ogni file della vecchia cartella, poi un fileadd per ogni file della nuova: non c’è alcun messaggio che annuncia il nuovo selectedfolder, che esiste solo nel dump.

A ogni passaggio il server invia inoltre messaggi uc files e folders contenenti gli elenchi completi: un client può quindi applicare gli eventi evt uno per uno, oppure semplicemente sostituire i propri elenchi con questi uc.

Costruire l’URL di un file

I percorsi di files sono relativi al webroot e iniziano con /. L’URL di un file è l’URL di base dei media del server (http(s)://hostname/ostmedia/, vedi la nota « URL media » del Modello dati) seguita dal percorso. Attenzione alla / iniziale: concatenarla a una base che termina già con / dà una doppia //.

Ciò che l’evento non fa

Il server rileva l’aggiunta, l’eliminazione e la ridenominazione di file, non la modifica del contenuto di un file esistente: un’immagine riscritta con lo stesso nome non produce alcun evento. È il caso delle immagini di anteprima dei moduli, il cui URL resta identico a ogni ripresa: un client deve aggiungere un parametro di cache-busting (?t= + marca temporale) quando ricarica un’immagine dopo un aggiornamento della sua proprietà.