IGWiki Main Page


Ricerca pagine

Novembre2017
  1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30    
       

IGSuiteAppunti sull'interfaccia tra IGSuite e Funambol (Bozza) (Documento scaduto)
  Modifica PaginaStorico paginaProprietàGet PdfVisualizza il documento in formato stampabile.Posso Aiutarti

Funambol JSON Connector

Post su forum link.

IGSuite connector


Accesso al database

Come gestire l'accesso al database da parte del connettore?

Il connettore sarà scritto in Java a può usare i driver JDBC per accedere al db. Va bene o si vuole in qualche modo interfacciare il connettore al perl per far sì che sia comunque IG.pm ad accedere al database?
LucaS (06.06.2009) La prima che hai detto! secondo me non c'è motivo per collegare il connettore a IG. Il connettore deve fare il suo lavoro autonomamente. Tanto l'autenticazione degli utenti (che è l'unica cosa che mi viene da pensare) è gestita dal server funambol. L'unica cosa da architettare è trovare un sistema per consegnare al connettore i dati necessari alla connessione al db (login,pwd,host etc) ma la cosa si risolve facilmente con un piccolo script Perl (che usa IG.pm) e che se chiamato restituisce questi valori al connettore. Per ora non te ne curare andiamo oltre e realizziamo il prototipo

SyncSource

Per implementare il metodo getUpdatedSyncItemKeys(Timestamp since, Timestamp to) occorre fare in modo che gli oggetti (eventi di calendario, contatti) mantengano due campi Timestamp relativi alla creazione e all' ultima modifica. Campi da aggiungere sia agli eventi dell'agenda che ai contatti.
LucaS (06.06.2009) sei sicuro che per questo metodo occorra anche il campo relativo alla creazione? in fondo il metodo dovrebbe restituire solo gli elementi "modificati" all'interno di un certo range. Comunque nessun problema ad inserire nelle tabelle contacts e calendar due campi BIGINT che potremmo chiamare rispettivamente ctimestamp e mtimestamp. Naturalmente alla creazione dell'elemento mtimestamp sarà uguale a ctimestamp. In DBStruct.pm occorrerà inserire delle query che popolano questi due valori con un campo predefinito che poi sceglieremo (credo non sia importante il suo valore nella fase iniziale della sincronizzazione). Ci penso io? procedo?
Ale (06.06.2009): Sì, per questo metodo serve effettivamente solo il timestamp di creazione.

Il metodo getNewSyncItemKeys(Timestamp since,
Timestamp to)
richiede invece che venga tenuta traccia almeno della data di creazione (o anche dell'ora?) di ogni elemento sincronizzabile.
LucaS (06.06.2009) Che vuoi dire con "anche dell'ora?" un valore timestamp contiene data e ora (o meglio può fornire). Ma se gli argomenti di getNewSyncItemKeys sono Timestamp since e Timestamp to credo che il connettore debba interrogare il db sul campo che inseriremo "ctimestamp" utilizzando proprio questi due argomenti.
Ale (06.06.2009): Sì sì... la domanda sull'ora l'avevo inserita prima di capire effettivamente quale fosse il formato di timestamp... nel caso potessimo non aggiungere campi timestamp, ma usare quelli esistenti... ma meglio aggiungere due campi timestamp BIGINT.

Il metodo getDeletedSyncItemKeys(Timestamp since,
Timestamp to)
richiede di tenere traccia degli elementi cancellati tra i due timestamp specificati (si possono usare le informazioni registrate system_log ricostruendo il timestamp a partire dalla data+ora, la data/ora in system_log è sul fuso orario locale... per ricostruire il Timestamp occorre la data/ora in GMT)

A cosa serve il metodo getSyncItemKeysFromTwin(SyncItem syncItem)???
LucaS(06.06.2009) Ho provato a cercare su internet e sembra che questo metodo serve a verificare (quando si fa lo slow sync) se un Item è già presente all'interno del db. Il link all'articolo in Italiano sopra riportato dice questo: Risulta utile conoscere anche il prototipo di getSyncItemKeysFromTwin, che è così definito: public SyncItemKey[] getSyncItemKeysFromTwin(SyncItem syncItem) A questo metodo viene passato un oggetto di tipo SyncItem e ritorna le chiavi di più oggetti simili, se esistono. Gli oggetti sono creati in createItem avendo specificato un identificatore, ovvero la chiave dell'oggetto, il contenuto e lo stato; successivamente viene istanziato un nuovo SyncItemImpl, che setta il valore di BINARY_PROPERTY al contenuto corrente. Di più non ti so dire perchè il Java mi è totalmente oscuro, proverò a cercare ancora su Internet.


Timestamp è la classe java.sql.Timestamp link, per cui i timestamp dei vari oggetti da sincronizzare possono essere memorizzati utilizzando un campo BIGINT (BIGINT è supportato dal framework?) che conterrà i secondi trascorsi da January 1, 1970, 00:00:00 GMT.
LucaS (06.06.2009) Non ho capito cosa vuoi sapere. A te o meglio al connettore non interessa il framework ma solo il db che conterra i timestamp nei due campi di tipo BIGINT. Comunque in perl non dovremo far altro che inserire nei due nuovi campi ctimestampe mtimestamp il valore della funzione time() che restituisce proprio i secondi trascorsi da 01.01.1970.
Ale (06.06.2009): L'unica cosa che volevo sapere era se il framework ha qualche problema ad usare campi BIGINT, ma mi pare di capire di no... Il resto è solo documentazione.


Nome: Funambol - Revisione: 0 - Autore: Forlani Alessandro (03.06.2009) - Modificata da: Forlani Alessandro (21.06.2011) - Categoria: Wiki - Scadenza: 03.06.2010 - Permessi di visualizzazione: Tutti indistintamente - Permessi di modifica: Condiviso con tutti gli utenti - Copyright © Ortolani Luca All right reserved

Need account? Non hai un account?
Login
Password


Ultimi documenti modificati
   
getrss