U1DB, la soluzione annunciata da Canonical nel corso dell’Ubuntu Developer Summit (USD) di Precise Pangoline in ottobre, è stata rilasciata in forma d’anteprima. In occasione del rilascio Stuart Langridge è intervenuto per chiarire cos’è – e, soprattutto, cosa non è – U1DB. Fugando ogni dubbio sul database utilizzato da Ubuntu One.
O, almeno, ha provato: l’unica conferma di Langridge è che U1DB non è un database e Canonical non intende crearne uno a sé. Ancora, U1DB è utilizzabile con qualunque database… tuttavia, al momento esiste soltanto un’integrazione con SQLite. La confusione su U1DB è stata creata, più che da Canonical, attorno a essa. Specie da Apache.
La contraddizione nella quale sono caduto anch’io è dovuta ai termini: come avevo – in ultima istanza – ipotizzato, Canonical non sostituirà affatto CouchDB. Rimpiazzerà, invece, Desktop CouchDB. Ubuntu One avrà soltanto un nuovo “connettore” per il database, che rimarrà lo stesso. E, cioè, CouchDB con le patch rigettate da Apache.
Un’ipotesi, tutta da confermare, sulla possibile sostituzione del database riguarda SQLite: poiché Ubuntu One è una risorsa per il cloud computing, le applicazioni mobile utilizzeranno SQLite al posto di CouchDB. E U1DB svolgerà le funzioni deputate a Desktop CouchDB sul desktop. Certo, avrebbero potuto scegliere dei nomi distinti.
Tant’è che insieme all’anteprima di U1DB Canonical ha aperto anche Sharedbridge. Quest’ultimo sarà un “ponte” in Vala per l’utilizzo di U1DB sul desktop con SQLite. Soltanto quando U1DB avrà raggiunto un adeguato livello di stabilità, SQLite e Sharedbridge potrebbero rimpiazzare definitivamente CouchDB e Desktop CouchDB sul desktop.
Sarebbe stato più chiaro produrre uno schema. In pratica, SQLite dovrebbe sostituire CouchDB e U1DB – scritto in Python – sarà il “collante” tra Sharedbridge (Vala) e i futuri porting per Android (Java) e iOS (Obj-C) in sostituzione a Desktop CouchDB. Per adesso, Ubuntu One è su CouchDB e potrebbe restarci. Desktop CouchDB escluso.
Via | Canonical
Seguici
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
romfladef
23 dic 2011 - 09:28 - #1Provo a riprodurre uno “schemino”, perché ha fatto venire l’emicrania anche a me la questione…
Prima:
Ubuntu One → Apps → Desktop CouchDB → CouchDB
Dopo:
Ubuntu One → Apps → U1DB → CouchDB
Poi:
Ubuntu One → Apps → U1DB → Sharedbridge → SQLite
Meglio di così, temo sia difficile sintetizzarlo!
Kim Allamandola
23 dic 2011 - 10:31 - #2Hum… Continuo ad essere perplesso: SQLite è sicuramente light, è stra-usato
in ambito mobile; CouchDB è sicuramente interessante (e un po’ pesante anche
se meno dei DB elefantiaci classici) ma sono completamente diversi. Un ORM o
Connector o chiamatelo come vi pare che possa, con la stessa “interfaccia”
lato applicazione usare come backend SQLite o CouchDB indifferentemente la
vedo o “complicata” (aka pesante, buggata, scomoda) o assai limitante…
Continuo a puntare su redis sperando in un layer tipo l’arc dello zfs che
permetta di rinunciare alle performance della ram mantenendo invariato il
resto e che lato applicativo possa essere usato come yaml/pickle…
winebar
23 dic 2011 - 20:23 - #3@Kim Allamandola: rinunciare alle performance della RAM. E hai detto poco, dato che è il dispositivo di memorizzazione più veloce. Certo appena manca la corrente perde i dati, per ora.
Penso che con il tempo passare da CouchDB a SQLite sia la cosa migliore, certo è che in Canonical quando decideranno di effettuare il passaggio dovranno impegnarsi parecchio per offrire un servizio che non faccia notare le differenze tramite numerosi bachi. Dovrebbero fare ciò che n0on hanno fatto con Unity 3D: test interni fino allo sfinimento e a una maturià degna di questo nome.
barra
24 dic 2011 - 10:43 - #4?
sul post di Canonical mi pare che ci sia scritto tutt’altro…. Sqlite non viene nominato salvo per gli smartphone.
Da quel che ho capito poi Sharedbridge sarà un connettore che se implementato sui singoli applicativi (es. banshee, RB, shotwell) andrà collegare i DB interni al db personale su Ubuntuone.
E aggiungo: probabilmente alla fine della fiera il tutto è stato creato per togliere dal pc desktopcouchdb e garantire maggiore flessibilità (vedi i casini con il connettore per FF che non ha mai funzionato a dovere….).
Kim Allamandola
24 dic 2011 - 12:51 - #5@winebar #3
il rinunciare alle performance della ram è relativo ai sistemi embedded che
per caratteristiche hw non possono occupare granché la ram. Io penso a redis,
n volte più leggero e veloce di couch (di cui sono stato un fan dalla prima
ora e tutt’ora adoro la gestione fs based dei file “allegati”) che sui desktop
può essere così com’è (e a differenza di membase/memcached è persistente pur
tenendo il datastore in ram per questioni di performance) mentre sui sistemi
mobile può usare una sua vram sulla flash di sistema.
Ad ogni modo il mio punto è: la maggior parte delle applicazioni desktop e
mobile si sposa perfettamente con sistemi come yaml/pickle ovvero non ha
complesse dipendenze od operazioni da fare sui dati mentre c’è un enorme
vantaggio dell’avere le proprie strutture dati/classi/* del proprio linguaggio
di programmazione persistenti su disco e magari anche maneggiabili dagli
umani fuori dal sw (es. modificare a mano un file yaml).
con Yaml/Pickle ad es. puoi salvare delle tue classi semplicemente aprendo
un fh e dando {pickle,yaml}.dump(tua_struttura_dati/classe) e puoi in un
secondo tempo ricaricarla paro-paro passando un fh a {pickle,yaml}.load()
non hai cursori da gestire, query ecc. L’unico vincolo è che i dati devono
essere serializzabili, cosa cmq facile da realizzare. SQLite al contrario è
un mini-db sql file-based, non puoi gestire i dati allo stesso modo e poter
fare un layer tipo ORM in mezzo la vedo assai “sporca”… Per questo pur
riconoscendo che SQLite *oggi* è ottimo in ambito mobile/embedded preferisco
dedicarmi ad una nuova soluzione che non ad un’interoperabilità con SQLite…