Following on from my previous email, I have a bunch of
observations gleaned from wading through the code. I would dearly love
some indication of whether my observations are correct (or
- only handles application/vnd.syncml-xml,
ie does not handle WbXml, but looks to be extensible (see comment
below about XmlIo)
- synchronizes XML DOMs, using files as backing stores on both
client and server
- uses interfaces for the DOM, but need to re-implement com.reaxion.tequila.syncml.xml.node.XmlIo to
use another DOM or another XML serialization, eg WbXml. A factory would
be helpful here.
- changes to the client DOM must be done through the kSync
API to be recorded.
- changes to the server DOM presumedly the same, but not sure
- DOM change history is recorded and used to limit
synchronization traffic. Sadly, DOM change history is not persisted, so the
whole file is sent? when a synchronization occurs after a restart
- changes made directly to the XML backing store files are
only picked up on a restart
- the design seems tightly attached to XMLSyncServerDocument. Some refactoring would be required to
insert another document type (say a file document), including:
- use of a factory for constructor calls in ServerSession and SyncServer
- separation of XML methods defined in IXMLSyncDocument and inherited in IXMLSyncServerDocument from the server document related
fields defined in the latter.
- not fully SyncML v1.1 compliant:
- RespURI, Cred, Meta fields missing from SyncHdr element
Just spent another
day wading through kSync, trying to figure out how it works and how to apply
it. Judging from what I can see of the mailing list, I am not
Howvever, the day
was not without gain. I finally discovered that kSync synchronises DOMs,
and not files. The files are "merely" used as backing store for the
in-memory DOMs. Ah ha!!
question: when will v2 become publicly available. I'm not sure how many
days I want to invest in wading through the source if it will all go out the
window when v2 arrives.