[Gfoss] R: Rilascio MapStore 1.5.1 con versione Mobile per Android

[a.furieri a lqt.it]

visto che in piu' d'uno mi avete tirato per la giacchetta,
rispondo in ordine rigorosamente caotico ed arruffato:

On Sun, 23 Mar 2014 19:24:46 +0100, Diego Guidi wrote:
> Però una cosa la voglio dire:
> "
> Si in effetti siamo d'accordo, non è che gli ingegneri informatici
> servano a molto per la programmazione informatica
> "
> Ovviamente la frase è sarcastica, ma l'atteggiamento di tanti non mi
> stupisce
>

non so, non mi intendo: pare una baruffa tutta interna tra ingegneri
informatici; dal basso della mia laurea in scienze naturali evito
saggiamente di metter becco nei loro riti ingegnereschi :-)

personalmente mi sono sempre attenuto al saggio approccio di
Donald Knuth, l'autore di "The Art of Computer Programming"
... e credo che gia' il titolo da solo la racconti molto lunga:
difficilmente Ingegneria ed Arte riescono ad andare armoniosamente
a braccetto, qualche screzio e' facilmente prevedibile ;-)


On Sun, 23 Mar 2014 14:11:56 -0700 (PDT), aborruso wrote:
> Ciao Diego,
>
>
> D_Guidi wrote
>> P.S: maledetti thread, comunque!
>
> solo per dirti "maledetti thread" è geniale e fa prendere anche un 
> po' di
> respiro
>

un illuminante e saggio parere di Richar Hipp, il padre di SQLite:

"Threads are evil. Avoid them." [1]
... chi li conosce bene cerca accuratamente di evitarli;
oppure si assume il rischio di avventurarsi consapevolmente
in acque torbide ed altamente pericolose ;-)

[1] https://sqlite.org/faq.html#q6


On Sun, 23 Mar 2014 20:39:03 +0100, aperi2007 wrote:
> A suo  tempo , quando mi giunse questa tua notizia, mi informai e
> emerse che la geos non è thread-safe
> (lo sapevi ?)
> Alcune parti in realta' lo sono , ma solo la parte dei messaggi, il
> resto non lo è.
> Per cui la parte rilevante, quella della elaborazione non lo è.
> Io non sono un programmatore di geos, ma se chi lo è mi dice che non
> è thread-safe io gli credo.
> Queste notizie a te erano state fatte pervenire.
>
> Con la ovvia conclusione che se la geos non e' thread-safe non ha
> senso parlare di inizializzarla in modalit'a thread-safe.
> e comunque spatialite per questo ha implementato dei meccanismi di
> lock che se non sono thread-safe almeno impediscono le collisioni.
>

non e' del tutto vero; giusto per puntualizzare e precisare meglio:

- la GEOS ha due set di funzioni completamente distinti (la stessa
   funzione ha sempre due nomi diversi): una versione e' thread-safe,
   l'altra invece assolutamente no.
   giusto per semplificare la vita, non e' invece thread-safe la
   gestione dei messaggi di errore, a meno di non avventurarsi in
   soluzioni abbastanza "creative/fantasiose" (come quelle poi
   adottate da splite).

- neppure la PROJ.4 e' intrinsecamente thread-safe.
   occorre applicare alcune particolari avvertenze speciali nel
   codice che chiama le API di questa libreria.

- quella che invece non e' assolutamente rientrante (= thread unsafe)
   e' la LWGEOM, visto che e' stata inizialmente concepita per 
PostgreSQL
   che non usa mai threads ma piuttosto usa sempre processi distinti.
   per chiamare in tutta sicurezza le API di LWGEOM e' quindi sempre
   prudente utilizzare un semaforo / mutex che schermi qualsiasi
   interferenza negativa tra eventuali threads concorrenti.
   insomma, riassumendo: nessuna di queste tre librerie e' nata fin
   dall'inizio per essere thread-safe.
   sono state poi rattoppate a posteriori per diventare thread-safe
   in seconda battuta, ma al prezzo di costringere tutto il codice
   chiamante ad una sostanziale riscrittura discretamente invasiva.
   informazione peraltro affogata qua e la nelle varie mailing list
   di progetto in modo abbastanza dispersivo, e mai chiaramente
   esposta nella doc di supporto (quando esiste).

- naturalmente, non possiamo certo tralasciare libsqlite3:
   che puo' essere thread-safe come anche assolutamente no.
   dipende tutto da come viene compilata (e secondo gli sviluppatori
   di SQLite, dipende anche dall'o.s. che si usa: p.es. pare che
   alcune versioni di RedHat alla prova dei fatti non siano minimamente
   in grado di supportare un effettivo multi-threading per SQLite).


On Sun, 23 Mar 2014 18:27:55 +0100, Simone Giannecchini wrote:
> Come problema ulteriore, spatialite stesso al momento dei test andava
> in crash a causa di problemi nel caricamento dinamico della libreria,
> cosa risolta dopo la fine del nostro studio e non so se già 
> rilasciata
> in forma stabile e ufficiale (mi pare di no, l'ultima versione è di
> Giugno 2013, noi abbiamo fatto i test durante l'autunno).
>

non era solo Java/JDBC a soffrire di questa criticita': il medesimo
problema si verificava tal quale anche con C# .NET e con altri
language-connectors piu' esotici (p.es. quello LISP per AutoCad,
di cui personalmente non immaginavo neppure l'esistenza).
viceversa non si verificava mai in ambienti "sani di mente" (C/C++)
che accedono direttamente alle API native senza nessuna ulteriore
contorsione piu' o meno indiretta (per capirsi: questa e' la
modalita' normalmente utilizzata dal provider QGIS, da GDAL etc).

come e' emerso pian piano dalla mailing list di SpatiaLite grazie
ad un certo sforzo collettivo della community, era l'intero
meccanismo di caricamento dinamico delle estensioni (su cui si
basano completamente praticamente tutti i language-connectors)
che si era andato progressivamente degradando di versione in
versione,
fino a non funzionare affatto con le due versioni piu' recenti.

dato che l'onda lunga degli aggiornamenti ha impiegato diverso
tempo prima di arrivare fino alla massa degli utenti, e dato
anche che le segnalazioni di malfunzionamento hanno faticato
a risalire a ritroso tutta la catena delle dipendenze fino ad
approdare finalmente sulla ML di splite, purtroppo il problema
e' emerso in tutta chiarezza solo con discreto ritardo.

situazione attuale: l'intero meccanismo di inizializzazione di
spatialite come estensione dinamica e' stato completamente
riscritto da zero durante l'autunno.
cosi' come e' stato riscritto da zero tutto il supporto per
le API di GEOS, PROJ.4 ed LWGEOM in modo tale da garantire
un'effettiva possibilita' d'uso anche nei contesti di tipo
multi-threading.

la versione di sviluppo e' stata successivamente testata abbastanza
estensivamente durante tutto l'inverno (anche grazie agli sforzi
di svariati testers esterni volenterosi), e pare quidni che ad oggi
sia piu' che ragionevole affermare che la configurazione finale
adottata e' assolutamente thread-safe e funziona sempre correttamente
tanto sotto Java/JDBC quanto sotto C# .NET (ed immagino quindi,
anche con qualunque altro language-connector).

ormai e' trascorso un lasso di tempo ragionevole, e quindi possiamo
procedere in assoluta sicurezza al prossimo rilascio della nuova
4.2.0 che sara' la prima versione completamente thread-safe di
spatialite.

conseguenza inevitabile: a questo punto sara' caldamente consigliato
cessare al piu' presto possibile qualsiasi forma di supporto e di
utilizzo negli ambienti server per tutte le precedenti versioni,
visto che sono *sicuramente* thread-unsafe, e quindi potenzialmente
nocive e/o instabili.


On Sun, 23 Mar 2014 18:27:55 +0100, Simone Giannecchini wrote:
> In buona sostanza, il nostro breve lavoro ha messo in luce una serie
> di criticità che richiedono lavoro per essere risolte. La cosa non è
> oltrettuto banale perchè non si lavora su campo libero, GeoTools ha
> già un modulo Spatialite vecchio di qualche anno che punta alla
> semplicità facendo embedding delle librerie native necessarie,
> staticamente compilate dentro alcune lib java (pagando però il prezzo
> di scalabilità pressochè nulla), proporre una versione che funzioni
> solo se sono installate librerie native di recente aggiornamento
> (anche visto il problema che spesso aggiornare le librerie sui server
> non è permesso)
>

e qua Simone ha infilato precisamente il dito nella piaga.

SQLite e' un componente sw per alcuni versi meraviglioso; ma ha anche
alcune specificita' (o vogliamo chiamarle piuttosto idiosincrasie ?)
assolutamente "speciali" che non pare saggio ignorare ....

1) *non* e' client-server. di fatto lo SQL engine e la connessione
    client sono un unico continuum indistinto entro lo stesso spazio
    di indirizzamento, senza alcun tipo di separazione.

2) la logica delle API di libsqlite3 non somiglia minimanente a
    quanto si trova normalmente nelle librerie client p.es. di MySQL
    o di PostgreSQL; ma non dovrebbe stupire piu' di tanto, visto
    che non e' un DBMS client-server.
    corollario: pretendere di incapsulare SQLite entro le maglie
    rigide e prefissate di schemi astratti concepiti per i DBMS
    client-server (JDBC, ODBC e compagnia bella) non e' il modo
    piu' "smart" per utilizzare SQLite.
    si aggiungono sicuramente ulteriori strati intermedi non
    strettamente indispensabili, e si rischia cosi' di
    introdurre inopinate cause di fragilita' in un'architettura
    che sarebbe invece di suo assolutamente solida e robusta
    (se utilizzata nel verso giusto per cui e' stata progettata,
    senza costringerla a controrsioni innaturali).

3) libsqlite3 ha molte decine di opzioni configurabili al build-time:
    alcune di queste ne stravolgono pesantemente il funzionamento.
    pare purtroppo che la fantasia perversa dei packagers/distributors
    si sia accanita per garantire che ciascuana distribuzione sia
    "simpaticamente" non-standard o per un verso o per l'altro.
    fortunatamente tutte le distro di sistema Linux sono "canoniche";
    ma p.es. quella Mac non lo e' affatto, e pure svariati
    language-connectors (p.es. PHP, Python) usano approcci a
    dir poco stravaganti o quanto meno "non convenzionali".
    lo stesso connector JDBC Xerial non e' certo un esempio di
    best practice, visto che si imbosca silenziosamente una propria
    copia privata interna di libsqlite3 diversa da quella di sistema.

4) purtroppo molte (troppe) distibuzioni hanno tempi di aggiornamento
    esageratemente lunghi: ancora si trovano normalmente in circolazione
    versioni di sqlite assolutamente obsolete (robaccia di tre o anche
    quattro anni fa) oggi praticamente del tutto inutilizzabile.
    noto invece con piacere che p.es. Fedora sta abbracciando con
    convinzione quella che pare l'unica soluzione ragionevole per
    SQLite, cioe' distribuire immediatamente ogni nuova versione
    giusto qualche settimana dopo il rilascio iniziale ed abbandonando
    immediatamente qualsiasi supporto per tutte le versioni
    precedenti.
    short rationale: sqlite3 ha delle API/ABI assolutamente stabili
    nel corso degli anni; si aggiunge sempre qualcosa di nuovo, ma
    non si modifica mai nessuna API gia' adottata in precedenza
    (se proprio e' concettulmente aberrante la si depreca; ma non
    verra' mai soppressa in nessun caso, proprio per continuare a
    garantire eterna compatibilita' a ritroso con le vecchie versioni).
    quasi sempre ogni nuova versione SQLite e' accompagnata da
    note di rilascio che segnalano qualche criticita' (anche grave)
    riscontata nelle versioni precedenti, che nessuno mai si
    sognera' di rattoppare in back-porting.
    ergo insistere a distribuire e supportare le vecchie versioni
    significa di fatto distribuire piu' o meno consapevolmente
    sw bacato, mal funzionante e potenzialmente nocivo.
    ... con buona pace di chi magari crede ingenuamente  che sia
    "piu' stabile" semplicemente perche' fa parte di una distro
    "ufficiale" col bollino certificato DOC, e perche' cosi i
    sysadmin si sentono sereni e rassicurati :-D

5) infine non puo' mancare lo zampino del diavolo: a dispetto di
    tutto quanto sopra, libsqlite3 e' cosi' piccola e compatta che
    la maligna tentazione di ricorrere allo static linkage e'
    sempre pericolosamente in agguato.
    va benissimo per componenti stand-alone, ma nel caso di
    frameworks molto complessi e ramificati come quelli che di
    norma si trovano sulle piattaforme server e' sempre una pessima
    soluzione, che finisce inevitabilmente per incasinare le cose
    oltre l'umanamente immaginabile.


giusto due considerazioni finali: SQlite e' stato esplicitamente
progettato per essere un componente "embedded" largamente e
facilmente configurabile al build time.
e' del tutto ovvio che l'intenzione originale degli autori era
proprio quella di puntare molto decisamente sullo static linkage
(non ne fanno alcun mistero, lo sostengono a gran voce), in modo
tale che ciascun singolo processo si portasse "direttamente nella
pancia" un proprio motore SQL interno accuratamente configurato
e pazientemente ottimizzato a seconda delle proprie specifiche
necessita'. e che fosse nel contempo assolutamente refrattario
a qualsiasi interferenza esterna (p.es. dovuta ad aggiornamenti
di sistema, oppure all'installazione di altri componenti).

insomma, un componente decisamente "da smanettoni" molto skillati,
e ben consapevoli di cosa stanno facendo (oserei dire: molto
Artisti, e per nulla Ingegneri).
e quindi niente affatto pensato per conformarsi ai sacri canoni
ed a  tutte le regolette astratte che invece stanno tanto a
cuore  (anche giustamente, per carita') ai system packagers ed
ai sysadmin.

non a caso, il terreno dove sqlite ha fatto strage e' proprio
quello dei sistemi mobile/embedded, dove e' stato felicemente
strizzato, stiracchiato ed accrocchiato in millemila salse diverse,
ma sempre con pieno successo.

naturalmente alla fine SQLite ha finito col conquistarsi un suo
spazio anche negli ambienti server e desktop: magari anche grazie
all'uso di qualche language-connector piu' o meno esoterico.
resta il fatto oggettivo ed incontrovertibile che il team di
sviluppo di SQLite si e' assunto una sorta di "impegno ufficiale"
di corretto funzionamento nei confronti di un unico language-connector
(a parte ovviamente le API C): Systema.Data.SQLite per ADO .NET

tutti gli altri connector (proprio tutti) sono semplicemente
"as is", ed non hanno nessunissimo avallo ne' ufficiale ne'
ufficioso da parte del team SQLite (che spesso non manca di
lesinare critiche per alcune implementazioni giudicate poco
adeguate e fonte di problemi senza fine).

inoltre basta semplicemente leggersi (anche saltuariamente) la
loro mailing list per scoprire che l'uso di qualsivoglia distro
pre-pacchettizzata di sistema e/o di linguaggio viene sempre
caldamente sconsigliato in modo sistematico.
come dicevo in premessa, non sono un ing. informatico e quindi
non mi arrischio ad esprimere giudizi di merito ... ma tutto
questo qualcosa di significativo vorra' pur dire, no ? ;-)

sara' magari colpa dei miei remoti studi zoologici, ma a volte
ho un po' come l'impressione che nei confronti di SQLite i
system packagers abbiano un po' l'atteggiamento di chi pretenda
di montare un pesante basto da mulo sulla schiena di un coniglio
solo perche' da qualche parte esiste una regoletta fissata a
priori una volta per tutte e che dice piu' o meno cosi':

"qua siamo abituati a lavorare sempre con i muli: e' vero che
tu sembri un po' gracilino e cammini saltellando in modo buffo
(sarai mica gay per caso ?), ma comunque sei peloso come un mulo,
hai quattro zampe ed una coda esattamente come un mulo, mangi
erba proprio come un mulo, ed hai anche le orecchie lunghe da
mulo; quindi devi proprio essere un mulo.
allora fai meno storie, mettiti in coda assieme agli altri e
prenditi il tuo basto bello carico come fanno tutti i muli"

my 2 cents,
Sandro