[Gfoss] Rilascio MapStore 1.5.1 con versione Mobile per Android

Lun 24 Mar 2014 09:48:38 CET

Andrea, non abbiamo ancora esaminato insieme i risultato 
dell'approfondimento.
Visto che l'ho commissionato io devo precisare:

- il comportamento multithread è parte dell'incarico non per le 
implicazioni geoserver ma perchè volendo usare l'accoppiata 
geotools-spatialite in ambito web servlet siamo a tutti gli effetti in 
una casistica multithread a prescindere da geoserver
- se da questo lavoro potesse venire un buon supporto di spatialite per 
geoserver è un valore aggiunto per la comunità, quindi questo aspetto 
era sicuramente da indagare e quindi parte dello studio. Poi si sarebbe 
in seguito deciso in funzione delle complicazioni/costi se perseguirlo o 
meno
- ho ricevuto da qualche mese il risultato dello studio, che evidenzia 
problemi e possibili soluzioni. Non immediate ma nemmeno impossibili. 
Devo ancora approfondirlo per poi parlarne con gli altri soggetti 
interessati, tra cui Andrea, per decidere se e come muovermi.
Quindi non siamo andati avanti dipende dalle priorità (non si fa a tempo 
a seguire tutto..) nostre ma anche tue Andrea...

Il 23/03/2014 20:39, aperi2007 ha scritto:
> 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 a 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