R: Rilascio MapStore 1.5.1 con versione Mobile per Android

[D_Guidi]

Devo dire che già dalla email iniziale immaginavo che il tutto sarebbe andato a finire male, e onestamente ho combattuto parecchio contro me stesso per non intervenire rispondendo alle varie mail perlomeno sottolineando la leggerezza e superficialità di tanti commenti.
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, ahimè. Di fatto, oramai sappiamo più cose dei laureati in chimica, perché abbiamo letto su internet che per fare la fusione fredda basta la coca cola e le mentos ma le multinazionali non ce lo dicono, o dei medici, perché l'aids si cura con il balsamo come è scritto su Wikipedia ma l'onu l'ha creato per tenere sotto controllo le nascite. Sarà colpa dei templari informatici se spatialite non è thread-safe, sicuro sicuro.

Per il resto, ed in generale (e vale soprattutto per me che me lo scordo troppo spesso) occhio a giungere a conclusioni affrettate, soprattutto se e quando le conclusioni sembrano ovvie:  significa che molti probabilmente vi sta sfuggendo più di una cosa. 

P.S: maledetti thread, comunque!

---

Da: [hidden email]
Inviato: ‎23/‎03/‎2014 18.28
A: [hidden email]
Cc: [hidden email]
Oggetto: Re: [Gfoss] Rilascio MapStore 1.5.1 con versione Mobile per Android

Salve Andrea,
trovi le mie risposte inline sotto.

> Interessante questo mapstore 1.5.1
>
> Veod che gestisce pure un db spatialite.
>
> Come RT abbiamo finanziato anche uno studio per vedere se si riusciva a far
> funzionare spatialite con l'ambiente java.
> Ma la ditta a cui per vie traverse era stato dato l'incarico, una ditta
> esperta su geotools, non ci risulta che alla fine avesse concluso alcunche'
> di significativo.
>

Onestamente, essendo GeoSolutions un' azienda con sede legale e
operativa in Toscana che da lavoro a 15 persone di cui almeno 10
residenti in Toscana facendo il 70% del fatturato all'estero e pagando
circa 14k di IRAP l'anno, ci dispiace (a me e al management di
GeoSolutions) dover constatare questo ormai ovvio risentimento nei
confronti di GeoSolutions da parte della nostra regione con cui
peraltro non abbiamo MAI lavorato direttamente.

In qualità di rappresentante di GeoSolutions mi sento in dovere di
rispondere ancora una volta puntualizzando alcuni aspetti non solo dal
punto di vista tecnico e se questo comporterà di non lavorare piu' con
enti vicini o legati a RT lo prenderò come uno stimolo in piu' per
decidermi finalmente a spostare l'azienda all'estero. Fatto questo,
GeoSolutions e tutti i  suoi collaboratori dovranno necessariamente
smettere di intervenire su questa lista per evitare che l'immagine
aziendale venga deliberatamente danneggiata senza apparenti motivi e,
a mio parere, spesso con critiche fuori luogo e scarsamente
documentate tecnicamente.

Aggiungo anche che vedendo come altre regioni e province italiane ma
anche altri paesi (tutti) proteggano le loro aziende (spesso dobbiamo
fare forzatamente da subcontractor per lavorare all'estero pagando
pesante dazio) questa situazione è quantomeno assurda.


Andando sul lato tecnico, innanzitutto, il supporto a spatialite di
cui si parla si limita alla versione Android che non ha niente a che
fare con il java standard come sicuramente saprai in quanto il codice
non è (quasi) mai portabile tra una JVM standard e Dalvik.

Oltretutto si basa su una versione non aggiornata di spatialite e NON
usa driver JDBC ma istanzia la libreria e parla con essa direttamente
via JNI, ergo mi sfugge il parallelo e sarei portato a pensare che sia
solo un modo, come spesso è accaduto anche in passato, per criticare
trasversalmente visto che la azienda che citi siamo noi.

Visto che ci hai citato spiego l'antefatto. Spatialite si puo' usare
abb tranquillamente in applicativi desktop basati su Java, ma su
applicativi lato server come GeoServer, perlomeno al  momento in cui
abbiamo fatto il famoso studio di ben 9 ore (o giu' di li non ricordo
nel dubbio posso anche condividerei timesheet giornalieri e le
relative fatture) aveva grossi (enormi?) problemi di gestione di
thread multipli e di scalabilità (questo a livello dei driver JDBC).

Noi, nella persona di Andrea Aime non l'ultimo arrivato, abbiamo
evidenziato con test di scalabilità (che possiamo fornire a tutti) che
questi problemi esistevano ed abbiamo testato tutti i diver JDBC
esistenti. Abbiamo quindi chiesto di coinvolgere Furieri per validare
i nostri risultati visto che chi meglio di lui poteva commentare e non
mi risulta che qualcuno abbia detto che ci siamo sbagliati.

Senza voler criticare Furieri, mi ricordo una sua email girata anche
in questa lista dove evidenziava (su suggerimento di Even Roualt btw)
che spatialite inizializzava male GEOS (in modo non thread-safe) e
questo poteva portare a dei crash, cosa non accettabile in una
applicazione Java e che sicuramente era una delle sorgenti dei crash
che vedevamo.

In 9 ore di studio spero che sia ovvio per tutti che non si sarebbero
potuti risolvere tutti i problemi del supporto java verso spatialite e
noi abbiamo correttamente suggerito i tempi ed i modi per intervenire
nel caso ci fosse stato richiesto (dopo allego scambio email).



> Tante' che l'unico reale aiuto viene fornito dall'intervento dalle
> istruzioni di Furieri.
> Alla fien dei slmi, esperti, ingegneri, informatici, tante chiacchere,


Si in effetti siamo d'accordo, non è che gli ingegneri informatici
servano a molto per la programmazione informatica. Credo che saranno
d'accordo su questa osservazione anche tutti gli altri ingegneri
informatici che leggono la lista. Però in qualità di ingegneri
informatici laureati in meno di 6 anni con lode almeno la
documentazione la archiviamo bene, per cui per chi fosse interessato
alcuni degli scambi, perlomeno la nostra parte è reperibile qui:

https://docs.google.com/document/d/1YzTeCyo6q1Lj5Kj3C3dsSOzBXs_2hne-f1wyBcqgWrQ/edit?usp=sharing

Diro' di piu', se qualcuno vuole posso anche passare le classi di test
che abbiamo scritto.


Dall'interazione con Furieri abbiamo poi appreso che in effetti l'uso
di Spatialite da Java in applicazione thread safe non è cosa
immediata, soprattutto con i binari già disponibili nei pacchetti
binari a disposizione nelle distribuzioni (la ricompilazione dai
sorgenti è spesso un tabù, una libreria che la imponga diventa in
questi casi inutilizzabile), cito un pezzo di mail dello stesso ( di
nuovo non me ne verrà, visto che sa che lo stimo):

"se mi passate la facile battuta, non parrebbe che quella di fare
sviluppo thread safe sia stata una priorita' elevata per tutti quanti
i principali team che curano le librerie di base C/C++ perlomeno non
prima degli ultimi due anni o giu' di li quando poi ci e' premuniti di
inserire qualche patch appiccicata un po' in qualche modo e spesso
tenendole ben nascoste dentro a documentazioni un po' criptiche e con
pochissima visibilita'.

...

riassuntino ultra-short:

- tutte le versioni di spatialite rilasciate fino ad oggi (Aprile
2013, ndr) sono  sicuramente thread unsafe
"

Ora, lo studio lo si è fatto in autunno 2013, quindi i problemi di
thread safety erano risolti nelle versioni sorgente, ma non nelle
versioni binarie disponibili nelle varie distribuzioni.

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).

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) non è immediato, una nuova soluzione deve tener conto
delle problematiche di semplicità d'uso, e evitare di cozzare contro
il lavoro di supporto a GeoPackage, che per quanto non usi Spatialite,
usa lo stesso driver JDBC Xerial usato dal modulo Spatialite: il
driver JDBC in uso deve rimanere allineato, visto che non si possono
agganciare due volte le librerie native di sqlite con versioni diverse
dallo stesso processo, ne conseguen che qualunque passo venga fatto
non si può limitare alla sola revisione del modulo Spatialite, ma
necessariamente coinvolge anche un aggiornamento dei moduli
GeoPackage.

Vista l'ampiezza dello sforzo necessario e le inevitabili discussioni
in comunità una operazione come quella sopra descritta richiede un
significativo sforzo in termini di tempo, cosa che noi abbiamo
sottolineato nelle nostre comunicazioni scritte con il committente.
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013

[aborruso]

Ciao Diego,

D_Guidi wrote

P.S: maledetti thread, comunque!

solo per dirti "maledetti thread" è geniale e fa prendere anche un po' di respiro

[a.furieri]

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

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013

[D_Guidi]

2014-03-24 10:53 GMT+01:00  <[hidden email]>:
> "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


non per niente adoro l'unico linguaggio che non ha thread, il javascript.
aspetta, oh cacchio... :(
http://www.w3schools.com/html/html5_webworkers.asp

Diego Guidi
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013

[Andrea Aime]

2014-03-24 10:53 GMT+01:00 <[hidden email]>:

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).

Si, di questo si era consapevoli, e l'opzione di riscrivere completamente

lo store per usare l'API di sqlite/spatialite direttamente è stata presa in considerazione.

Solo che... è un sacco di lavoro.

Gli store JDBC condividono una notevole quantità di codice, delegando le

differenze fra un database e l'altro a un paio di classi, il dialetto e l'sql encoder,

partendo da zero e usando un approcccio diverso da JDBC tutto questo corpo

di codice andrebbe riscritto per usare le API dirette di sqlite.

Senza considerare gli oltre 300 test automatici già disponibili per gli store JDBC, che

di nuovo andrebbero riscritti per uno store che non sia basato su JDBCDataStore.

Infine, ci sarebe il costo di manutenzione a lungo termine, una volta preparato

questo nuovo codice, chi lo mantiene a lungo termine?

Gli store JDBC hanno di bello che la condivisione di molto codice rende

lo sforzo di manutenzione piuttosto contenuto, e quando si implementa una

miglioria per una della basi dati spaziali, la si trova spesso già pronta, o

implementabile con piccolo sforzo, anche per le altre.

Ciao

Andrea

--

==

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK

for more information.

==

Ing. Andrea Aime 

@geowolf

Technical Lead

GeoSolutions S.A.S.

Via Poggio alle Viti 1187

55054  Massarosa (LU)

Italy

phone: [phone]

fax: [phone]

mob: [phone]

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

-------------------------------------------------------

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013

[Sandro Santilli]

On Mon, Mar 24, 2014 at 10:53:08AM +0100, [hidden email] wrote:

> 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).

Mi rinfreschi la memoria ?
I messaggi di errore vengono passati alla funzione che fornisci
con il "contesto" GEOS, dove fallisce la thread-safety ? Non puo'
essere che all'esterno di GEOS...

> - 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.

Confermo.

--strk;

 ()  ASCII ribbon campaign  --  Keep it simple !
 /\  http://strk.keybit.net/rants/ascii_mails.txt 
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013