Ciao Simone.
Interessante questo tuo dettaglio per cui te lasci l'italia per questo
mio intervento.
Ove, oltre tutto un aspetto non secondario era l'apprezzamento per il
tuo prodotto.
Per il resto mi pare che il tuo intervento sia esso stesso la migliore
risposta che io potrei darti.
Visto l'attegiamento che hai anche nei confronti dei tuoi collaboratori.
Ionon ci vedo niente di male nel recriminare visto che veod un prodotto
valido fare uso di spatialite su una piattaforma di per se' abbastanza
ostica (dalvik) e non avere niente di analogo su una piattaforma che non
è piu' complessa (java)
>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.
Quindi se capisco la tua spiega, secondo te è stato piu' facile portare
spatialite su dalvik piuttosto che su una piattaforma
Java Standard.
il porting di spatialite su Dalvik lo avete finanziato voi di
Geosolutions di vostra iniziativa ?
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).
Non ho dubbi che su geoserver non sia facile da usare, ma strnaamente a
me non risulta che mai ci si sia sognati di commissionare ad alcuna
persona di supportare spatialite su geoserver.
Se proprio devo dirla tutta, a me risulta che ci fossimo interessati per
la realizzazione di un driver spatialite per Geotools.
Evidentemente certe persone immaginano geotools e geoserver come due
faccie della stessa medaglia e non si puo' agire sull'uno senza agire
contestualmente anche sull'altro.
Questo pero' aumenta i costi a carico di chi finanzierebbe non credi ?
Comunque non sapevo di questo dualismo obbligato geotools-geoserver, lo
scopro ora.
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.
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.
Credevo che queste cose le avessi contemplate.
Invece capisco da questo tuo intervento che ti eri fermato ben prima.
Termino qui perche' vedo che fai un gran mescolone di tante cose.
In ogni caso io facevo un apprezzamento del tuo prodotto recriminando
sulla mancata occasione su spatialite con le geotools. E non potendo non
notare che pero' nel tuo prodotto alla fine spatialite ci è entrato.
bello o brutto che fosse.
Non credo che ci fosse niente di cosi' male in tale intervento.
Forse cercavi solo la scusa buona e io non sapendolo te la ho fornita ?
almeno dimmi grazie.
:)
A.
On 23/03/2014 18:27, Simone Giannecchini wrote:
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.
_______________________________________________
Gfoss@lists.gfoss.it
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
