Menu
▾
▴
opensync-devel
|
From: deloptes <del...@ya...> - 2011-10-23 10:41:03
|
Hi, guys, I'm thinking about writing a plugin that uses the synthesis engine. I read about synthesis last year, but I was busy with too many business stuff to work on something like this. My proposal is to discuss it here and I'm asking for input basically to work out the design. >From the akonadi-plugin experience it is clear what needs to be done on the opensync side, so I need some ideas how synthesis can be brought into the game. I was thinking perhaps to take over the syncml library, but it looks like there is too much SyncML stuff to care about, which is already done in synthesis. If one of you is interested to assist, please let me know. Your opinion and estimates are really appreciated. regards |
|
From: Chris F. <cd...@fo...> - 2011-10-24 21:24:54
|
On Sun, Oct 23, 2011 at 12:40:35PM +0200, deloptes wrote: > My proposal is to discuss it here and I'm asking for input basically to work > out the design. > >From the akonadi-plugin experience it is clear what needs to be done on the > opensync side, so I need some ideas how synthesis can be brought into the > game. > > I was thinking perhaps to take over the syncml library, but it looks like > there is too much SyncML stuff to care about, which is already done in > synthesis. > > If one of you is interested to assist, please let me know. I'm willing to help answer opensync questions and general C and C++ questions as I am able. I'm not a libsynthesis expert, so I don't have much to offer in that regard. It appears that libsynthesis is also an engine. I don't know if that will get in the way of turning it into an opensync plugin. You'll have to find out first if you can use libsynthesis like an API, or whether you have to use it like a plugin. Maybe other people more familiar with the library can answer this. - Chris |
|
From: Lukas Z. <lu...@pl...> - 2011-10-25 10:12:51
|
Hello, On Oct 24, 2011, at 23:14 , Chris Frey wrote: > On Sun, Oct 23, 2011 at 12:40:35PM +0200, deloptes wrote: >> My proposal is to discuss it here and I'm asking for input basically to work >> out the design. >>> From the akonadi-plugin experience it is clear what needs to be done on the >> opensync side, so I need some ideas how synthesis can be brought into the >> game. >> >> I was thinking perhaps to take over the syncml library, but it looks like >> there is too much SyncML stuff to care about, which is already done in >> synthesis. >> >> If one of you is interested to assist, please let me know. > > I'm willing to help answer opensync questions and general C and C++ questions > as I am able. I'm not a libsynthesis expert, so I don't have much to offer > in that regard. > > It appears that libsynthesis is also an engine. I don't know if that will > get in the way of turning it into an opensync plugin. You'll have to find > out first if you can use libsynthesis like an API, or whether you have to > use it like a plugin. > > Maybe other people more familiar with the library can answer this. I'm not familiar with Opensync, but I wrote most of libsynthesis. Indeed, libsynthesis is a SyncML engine which has two APIs: - one to use the library in an application to provide SyncML sync (client or server) - another for datastore backend plugins, which are *called* by the engine to read/write/delete data. So the question is if this can fit into the Opensync picture somehow. As libsynthesis was not designed to be integrated as a subsystem of an overall sync architecture as Opensync, it might be difficult. Best Regards, Lukas Zeller, plan44.ch lu...@pl... - www.plan44.ch |
|
From: Patrick O. <pat...@gm...> - 2011-11-01 20:14:51
|
On Fri, 2011-10-28 at 13:17 -0400, Chris Frey wrote: > On Fri, Oct 28, 2011 at 04:27:02PM +0200, Patrick Ohly wrote: > > This advantage also has a significant downside: the rest of OpenSync has > > no idea about the DevInf of the SyncML peer and thus cannot take that > > into account when reading or writing the local database. It is also not > > possible to provide the capabilities of the local side to the Synthesis > > engine because there is not one single peer locally (group concept of > > OpenSync). > > > > As a result, data will get lost when doing round-trip syncs. > > I'm not a SyncML expert, so I'm not familiar what this "DevInf" information > will be, nor why we would lose it, nor why it might be important. :-( > > Can you give me an example of what might be missing? DevInf, or more precisely, the CtCap part of it, describes which properties are supported by a SyncML peer. This corresponds to the OpenSync-internal capability description. You can use this information to avoid data loss when sending an item and getting an update back. The key problem is: if a certain property (like BDAY) was sent and doesn't come back, is that because the value was removed intentionally by the user (in which case he also wants it removed locally) or was it dropped by the peer because it doesn't support that property? CtCap answers that question. As Lukas said, the Synthesis engine uses that information to avoid data loss. That won't work when invoked as part of OpenSync. Nor can OpenSync do that job because a generic SyncML plugin based on libsynthesis can't report the necessary information back to the OpenSync engine. -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |
|
From: Chris F. <cd...@fo...> - 2011-11-01 21:00:46
|
On Tue, Nov 01, 2011 at 09:14:40PM +0100, Patrick Ohly wrote: > CtCap answers that question. As Lukas said, the Synthesis engine uses > that information to avoid data loss. That won't work when invoked as > part of OpenSync. Nor can OpenSync do that job because a generic SyncML > plugin based on libsynthesis can't report the necessary information back > to the OpenSync engine. Thanks for your explanations. Hopefully I understand this now. :-) Assumption: the "giant wrapper" opensync plugin will sync all SyncML devices at once. It would show up in the OpenSync group list as "bunch of syncml devices". So, in the case of us writing a "giant wrapper", one part of that would be a DB plugin to Synthesis that simulates an actual SyncML device, but writes the data to an sqlite database or something. This fake device would have its own capabilities list in the form of DevInf. So, this "device" would support _everything_, including for example BDAY, but other devices in the Synthesis SyncML group might not. Libsynthesis would make sure that the BDAY in our database would not get deleted. (I'm assuming this is true, otherwise, none of this works.) And if there was at least one other device that supported BDAY, this could update our copy as well. The giant wrapper OpenSync plugin would run a Synthesis sync first, at the beginning of the OpenSync sync; then create its own list of changes for OpenSync, based on its database; update its database with incoming OpenSync changes; and just before finishing, would run another Synthesis sync. In this case, Libsynthesis would make sure that other SyncML devices would not overwrite our BDAY, and the OpenSync capabilities list would make sure the same didn't happen on the opensync side. In the common case, there would just be one device in the Libsynthesis group and one app in the OpenSync group, and as long as the fake device's database supported every possible piece of data, nothing would be lost. What am I missing? :-) - Chris |
|
From: deloptes <del...@ya...> - 2011-11-03 01:17:51
|
Chris Frey wrote: > On Tue, Nov 01, 2011 at 09:14:40PM +0100, Patrick Ohly wrote: >> CtCap answers that question. As Lukas said, the Synthesis engine uses >> that information to avoid data loss. That won't work when invoked as >> part of OpenSync. Nor can OpenSync do that job because a generic SyncML >> plugin based on libsynthesis can't report the necessary information back >> to the OpenSync engine. > > Thanks for your explanations. Hopefully I understand this now. :-) > > Assumption: the "giant wrapper" opensync plugin will sync all SyncML > devices at once. It would show up in the OpenSync group list as > "bunch of syncml devices". As I understood there are about 48 functions exposed, so it won't be that kind of a "giant". > > So, in the case of us writing a "giant wrapper", one part of that would > be a DB plugin to Synthesis that simulates an actual SyncML device, but > writes the data to an sqlite database or something. This fake device > would have its own capabilities list in the form of DevInf. This is actually what libsyncml is doing and the current plugin is using the database from opensync. And the synthesis engine has it's own database - correct, or by DB you mean the DB on the device (i.e. the mobile phone)? Perhaps the plugin can use the DB with the API, so the logic may change here - we need to have a look what is needed and what is possible. > > So, this "device" would support _everything_, including for example BDAY, > but other devices in the Synthesis SyncML group might not. Libsynthesis > would make sure that the BDAY in our database would not get deleted. > (I'm assuming this is true, otherwise, none of this works.) > And if there was at least one other device that supported BDAY, this > could update our copy as well. > > The giant wrapper OpenSync plugin would run a Synthesis sync first, at > the beginning of the OpenSync sync; then create its own list of changes > for OpenSync, based on its database; update its database with incoming > OpenSync changes; and just before finishing, would run another Synthesis > sync. > > In this case, Libsynthesis would make sure that other SyncML devices > would not overwrite our BDAY, and the OpenSync capabilities list would > make sure the same didn't happen on the opensync side. > > In the common case, there would just be one device in the Libsynthesis > group and one app in the OpenSync group, and as long as the fake device's > database supported every possible piece of data, nothing would be lost. I think here is the question how and if it is possible to be done. Even if we use a DB, we do not need to support everything in the same time and in the same group, but just the subset that is common for the peers (i.e. akonadi and the mobile) When we discover/configure our opensync group members we already know what they support. (I usually double check the device config when initializing as I change setup on the way and forget to change back) So can we get this information when using libsynthesis (I suppose yes)? It is done actually by libsyncml at the moment and is working pretty well. Next step: opensync initializes and it will know what capabilities are provided by the peers in the opensync group (i.e. akonadi and mobile). We must provide those capabilities to the synthesis engine as DevInf and ask for a sync. We will receive exactly the data that both peers support (and this is what libsyncml is doing ATM), so when both engines know what they support before starting the sync, I don't see any problem to let them sync it. About the "correct order" of "doing things" in SyncML - this is exactly the reason why we want to use it and I think nothing will be wrong with it. Can you explain what you mean by "correct order" and "full controll of the sync"?. What does it mean? I would like to keep all of it as simple as possible, as simple things are great :-) thanks for the discussion, I really appreciate regards |
|
From: deloptes <del...@ya...> - 2011-11-09 22:10:06
|
As no one is posting here any longer and I have some free time and "Drang" (probably translated the best as desire here), I have started working on this by deriving the logic/structure from akonadi/syncml-plugin and SyncEvolution. I would appreciate some help on how classes and logic can be defined as app design is not my primary straight. My goal is to get the context work done first (initialize/finalize/configure/discover) I'm also concerned about the licenses of the final plugin, as synthesis and SyncEvo hold LGPL or similar ... so what kind of license will have the plugin?? regards |
|
From: Lukas Z. <lu...@pl...> - 2011-10-25 10:10:18
|
Hello Chris, On Oct 25, 2011, at 10:14 , Chris Frey wrote: > Thanks... I'm guessing you meant for this to go to the mailing list? :-) Yes, sorry. I just sent it again to the list. > If I wanted to just talk to a SyncML device, get latest changes, get all > changes, delete records, add/modify changes, and then disconnect, would > that be possible with libsynthesis? Unlike many of today's web APIs, a SyncML session has an awful lot of state - you can't use it to just ask for something in a REST-like manner. The order of how you have to do the read and write operations is very strict in SyncML. Much in libsynthesis is about getting this order right, including numerous workarounds for peers that do it wrong. So libsynthesis has to be in control of the sync session from start to end. On the DB backend API side, it calls out to plugins to get list of changes, read items, insert/update/delete items. On the application API side, you can edit the client settings (URL, syncmode etc. - much what you see in a phone SyncML client, or my iOS apps), then initialize a session, and then "step" through the session. This means, it's not a single syncNow() function that blocks everything for a long time, but you have your own main loop which repeatedly calls the SessionStep() API function until the sync is done. SessionStep() has different return values, and informs you when a SyncML message is ready to be delivered to the peer, or when a SyncML response is expected from the peer. So the implementation of transporting messages (via HTTP, BT, whatever) is not in libsynthesis, but must (can!) be done in the calling code. Best Regards, Lukas Zeller, plan44.ch lu...@pl... - www.plan44.ch |
|
From: deloptes <del...@ya...> - 2011-10-27 10:18:09
|
Lukas, thank you for your input, it is really great, that you posted this information. I just had an overview of the documentation and the sample code and had a look into SyncEvolution. I recall a discussion with Patrick and his analysis where he said it's virtually impossible because of opensync's architecture, so I want to find out if it is feasible at the end and some time and work is worth to put into this. I'll ask more questions in the future, but what I need as a starting point is a kind of overview of possible design. I'll need some time to read in the docs, but the benefit is clear, so I really appreciate this discussion. Lukas Zeller wrote: > >> If I wanted to just talk to a SyncML device, get latest changes, get all >> changes, delete records, add/modify changes, and then disconnect, would >> that be possible with libsynthesis? > > Unlike many of today's web APIs, a SyncML session has an awful lot of > state - you can't use it to just ask for something in a REST-like manner. > > The order of how you have to do the read and write operations is very > strict in SyncML. Much in libsynthesis is about getting this order right, > including numerous workarounds for peers that do it wrong. So libsynthesis > has to be in control of the sync session from start to end. > > On the DB backend API side, it calls out to plugins to get list of > changes, read items, insert/update/delete items. > > On the application API side, you can edit the client settings (URL, > syncmode etc. - much what you see in a phone SyncML client, or my iOS > apps), then initialize a session, and then "step" through the session. > This means, it's not a single syncNow() function that blocks everything > for a long time, but you have your own main loop which repeatedly calls > the SessionStep() API function until the sync is done. SessionStep() has > different return values, and informs you when a SyncML message is ready to > be delivered to the peer, or when a SyncML response is expected from the > peer. So the implementation of transporting messages (via HTTP, BT, > whatever) is not in libsynthesis, but must (can!) be done in the calling > code. > >From my point of view this is doable, also the current libsyncml is doing most of the same. I think if no one wants to maintain this library libsynthesis can safely replace it. Perhaps there would be some more work on the transport stuff, which I saw in SyncEvolution, but didn't have time to study. Chris, guys what is your opinion? Can we arrange a kickoff meeting in some irc or skype or so? regards |
|
From: Chris F. <cd...@fo...> - 2011-10-27 19:51:36
|
On Thu, Oct 27, 2011 at 12:17:40PM +0200, deloptes wrote: > From my point of view this is doable, also the current libsyncml is doing > most of the same. I think if no one wants to maintain this library > libsynthesis can safely replace it. Perhaps there would be some more work > on the transport stuff, which I saw in SyncEvolution, but didn't have time > to study. I suspect it is technically possible, but it might require some changes to libsynthesis. :-) Or maybe a large wrapper, which uses libsynthesis as intended, to sync into a local database, and then write an opensync plugin to sync against that database. > Chris, guys what is your opinion? Can we arrange a kickoff meeting in some > irc or skype or so? I think email is best. Until we have real technical details to discuss, or even proof-of-concept code, we might be just sitting around reading documentation together. :-) - Chris |
|
From: Lukas Z. <lu...@pl...> - 2011-10-27 22:07:23
|
On Oct 27, 2011, at 21:40 , Chris Frey wrote: > On Thu, Oct 27, 2011 at 12:17:40PM +0200, deloptes wrote: >> From my point of view this is doable, also the current libsyncml is doing >> most of the same. I think if no one wants to maintain this library >> libsynthesis can safely replace it. Perhaps there would be some more work >> on the transport stuff, which I saw in SyncEvolution, but didn't have time >> to study. > > I suspect it is technically possible, but it might require some changes > to libsynthesis. :-) Quite some changed, probably. It was designed to be multi-platform, to run a big SyncML server as well as be small enough to run on a Palm V, extendable via subclassing, configurable via XML - but not to integrate as a part of something else (as much I would like to have it that way today). It's pretty monolithic, with lots of dependencies between the internal core classes. > Or maybe a large wrapper, which uses libsynthesis > as intended, to sync into a local database, and then write an opensync > plugin to sync against that database. That sounds like an interesting approach. It'll sure be easier to implement and debug, and would nicely decouple the different designs. Still, by tuning that local database (which maybe can be reduced to some in-memory data forwarder), there's a lot of access into the data stream when needed. Best Regards, Lukas |
|
From: Patrick O. <pat...@gm...> - 2011-10-28 14:27:12
|
On Fri, 2011-10-28 at 00:07 +0200, Lukas Zeller wrote: > On Oct 27, 2011, at 21:40 , Chris Frey wrote: > > On Thu, Oct 27, 2011 at 12:17:40PM +0200, deloptes wrote: > > Or maybe a large wrapper, which uses libsynthesis > > as intended, to sync into a local database, and then write an > > opensync plugin to sync against that database. > > That sounds like an interesting approach. It'll sure be easier to > implement and debug, and would nicely decouple the different designs. This advantage also has a significant downside: the rest of OpenSync has no idea about the DevInf of the SyncML peer and thus cannot take that into account when reading or writing the local database. It is also not possible to provide the capabilities of the local side to the Synthesis engine because there is not one single peer locally (group concept of OpenSync). As a result, data will get lost when doing round-trip syncs. -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |
|
From: Chris F. <cd...@fo...> - 2011-10-28 17:28:35
|
On Fri, Oct 28, 2011 at 04:27:02PM +0200, Patrick Ohly wrote: > This advantage also has a significant downside: the rest of OpenSync has > no idea about the DevInf of the SyncML peer and thus cannot take that > into account when reading or writing the local database. It is also not > possible to provide the capabilities of the local side to the Synthesis > engine because there is not one single peer locally (group concept of > OpenSync). > > As a result, data will get lost when doing round-trip syncs. I'm not a SyncML expert, so I'm not familiar what this "DevInf" information will be, nor why we would lose it, nor why it might be important. :-( Can you give me an example of what might be missing? Thanks, - Chris |
|
From: deloptes <del...@ya...> - 2011-10-31 23:29:46
|
Chris Frey wrote: > On Thu, Oct 27, 2011 at 12:17:40PM +0200, deloptes wrote: >> From my point of view this is doable, also the current libsyncml is doing >> most of the same. I think if no one wants to maintain this library >> libsynthesis can safely replace it. Perhaps there would be some more work >> on the transport stuff, which I saw in SyncEvolution, but didn't have >> time to study. > > I suspect it is technically possible, but it might require some changes > to libsynthesis. :-) Or maybe a large wrapper, which uses libsynthesis > as intended, to sync into a local database, and then write an opensync > plugin to sync against that database. > I was reading SySync_config_reference.pdf [p.17] where it states 3.1 Basic Concepts The Synthesis SyncML engine performs three conceptually more or less separate tasks: • Running the SyncML protocol. [...] there is not a lot of configuration needed for the SyncML protocol engine itself. • Encoding and decoding the data that is synchronized with the SyncML protocol. SyncML itself is designed to synchronize any type of data, even proprietary, customer-defined types. However, to make a SyncML server or client interoperable, it must support some standard datatypes [...] vCard format for contact information and vCalendar for events and tasklists, and a number of RFC(2)822 based email formats for email synchronisation. [...] • Interfacing the SyncML data with a server's or client's database. The complexity of this task depends largely on the type and kind of database. [...] and also SDK_manual.pdf [p.7]: Synthesis AG makes their SyncML engine functionality available for customized database plug-in adapters as a Software Development Kit ( SDK ). Synthesis Plugin technology allows the customer to develop data base adapters or user interfaces without the need of understanding the details of the SyncML standard. It's an ideal division of work between Synthesis and the customer's project: Synthesis delivers a scalable, high performance SyncML OMA DS 1.2 engine, which is interoperability-tested against a huge variety of SyncML devices on the market. The customer only needs the specific knowledge to access his own data base framework or his own user interface which can be written in several programming languages. A small interface with only 48 + 23 well documented and easy-to-use functions is the bridge of interaction. All SyncML protocol details are hidden. There are mainly two sections of the SDK: • The data base interface ( DBApi ) for writing data base plugins (see chapter 4). • The user interface ( UIApi ) for writing user interfaces (see chapter 5). Both sections can be used completely independently, though some interface files are shared. So it really sounds doable. Perhaps we need to build something on top as you say (derived classes or wrapper or so). I would love also to read more about the JNI interface too and evaluate all possible options. Perhaps it is easier to implement something in java despite it will cause an overhead. I think I'll spend the time around Christmas not in coding but reading the documentation :-) as it looks more sophisticated. Something else: Do we need these http and ds client and server (that you see in libsyncml/libopensync-plugin-syncml - I didn't got it at 100% until now, because I have been using the obex-client in the config and I've never looked what is going on. [to be continued ...] kind regards |
|
From: Lukas Z. <lu...@pl...> - 2011-11-01 14:31:28
|
Hello On Nov 1, 2011, at 0:29 , deloptes wrote: > I was reading SySync_config_reference.pdf [p.17] where it states > [...] > > So it really sounds doable. Perhaps we need to build something on top as you > say (derived classes or wrapper or so). It's a matter of who calls whom. As long as you use libsynthesis as it is intended (doing all the SyncML work and call out to database access methods in the plugins when needed), it's straightforward. However, if there's a governing overall engine, which itself is designed to be the caller of plugin functionality rather than acting as a plugin, it gets more difficult. And as Patrick Ohly pointed out, multi-point sync between peers with different capabilities (supported fields) needs end-to-end awareness of these abilities or limitations. Between any two SyncML peers, libsynthesis has a lot of mechanisms built-in to obtain and use this meta information to avoid data loss in sync round trips. However, it was not designed to include non-SyncML peers into the capabilities negotiations. So sync between SyncML and non-SyncML peers would be rather uninformed, which usually leads to loosing data in round trips or creating duplicates. That's the real challenge in a multi-technology sync. > I would love also to read more about the JNI interface too and evaluate all > possible options. Perhaps it is easier to implement something in java > despite it will cause an overhead. > I think I'll spend the time around Christmas not in coding but reading the > documentation :-) as it looks more sophisticated. The JNI interface is not part of the opensource libsynthesis. > Something else: Do we need these http and ds client and server (that you see > in libsyncml/libopensync-plugin-syncml - I didn't got it at 100% until now, > because I have been using the obex-client in the config and I've never > looked what is going on. libsynthesis has no transport built-in, so you can use whatever you like. The examples from libsynthesis are all http, because OTA sync (over the air, internet based) was what actually was the demand of Synthesis AG customers at the time the library was developed. OBEX based SyncML mostly took place in the walled gardens of phone manufacturers, who had their own implementations. That has changed of course with SyncEvolution which offers both OBEX and http based on libsynthesis - and which has become, by far, the most advanced use case for (and contributor to) libsynthesis. Best Regards, Lukas Zeller, plan44.ch lu...@pl... - www.plan44.ch |
|
From: deloptes <del...@ya...> - 2011-10-31 23:52:46
|
Chris Frey wrote: > On Fri, Oct 28, 2011 at 04:27:02PM +0200, Patrick Ohly wrote: >> This advantage also has a significant downside: the rest of OpenSync has >> no idea about the DevInf of the SyncML peer and thus cannot take that >> into account when reading or writing the local database. It is also not >> possible to provide the capabilities of the local side to the Synthesis >> engine because there is not one single peer locally (group concept of >> OpenSync). >> >> As a result, data will get lost when doing round-trip syncs. > > I'm not a SyncML expert, so I'm not familiar what this "DevInf" > information will be, nor why we would lose it, nor why it might be > important. :-( > > Can you give me an example of what might be missing? > I can't give an example but the DevInf seems to be important for the sync process. I am not sure if we can sync forward to a local DB, than use opensync to sync with the peers and then sync back Here is some introduction to DevInf This document defines the Document Type Definition (DTD) for the XML representation of the Device Information document. This XML document describes the capabilities of the device and is used in SyncML data synchronization protocol operations. Data synchronization provides the means for two different networked object stores to remain in identical states. Different forms of data synchronization can be categorized into one of a number of topologies, based on the architecture used by a data synchronization server, or sync engine. Sync engines need to understand the features of a device they synchronize with. This information is often stored in a Device Information document on the target device. [syncml_devinf_v11_20020215.pdf, p.1] * there are too many docs there :-) but I don't find a single one about SyncML v1.2 (http://www.openmobilealliance.org/tech/affiliates/syncml/syncmlindex.html) regards *) full download link http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/syncml/syncml_devinf_v11_20020215.pdf |
|
From: deloptes <del...@ya...> - 2011-12-02 00:18:57
|
Hi, it took some time to get to the point where I can propose something meaningful, but I think I have now overall picture of how it can be done. Lukas Zeller wrote: > Hello, > > On Oct 24, 2011, at 23:14 , Chris Frey wrote: [...] > I'm not familiar with Opensync, but I wrote most of libsynthesis. Indeed, > libsynthesis is a SyncML engine which has two APIs: > > - one to use the library in an application to provide SyncML sync (client > or server) - another for datastore backend plugins, which are *called* by > the engine to read/write/delete data. > > So the question is if this can fit into the Opensync picture somehow. As > libsynthesis was not designed to be integrated as a subsystem of an > overall sync architecture as Opensync, it might be difficult. > I think it fits better then we suspect, if I understood correctly what I read. 1) In OpenSync's plugin you have the main sync and the data sync(s). The main sync will represent the UI API and the latter the datastore API. The calls can be handled either by the opensync plugin or passed to the engine and vice versa (depends what we want to achieve). This means A)the opensync plugin will drive the engine in the main sync and provide the transport etc. B) The data syncs will cover the data store work (and will act as DB plugins to the synthesis and object types to the opensync engine - i.e. contacts, events and so on). 2) Respective DevInf will be used/generated after or during both sides are getting discovered/configured. 3) If it is necessary for the synthesis engine to lead the sync, we can do this against the opensync database as Chris suggested, and we will mark the entries to know in which state they are (there is a mechanism in opensync to do so). I need to check again the opensync stuff on how it can be done in detail and I need some help in modelling the classes, as some of this goes above my knowledge. However the akonadi-plugin design is a very good example on how it can be done ... except that we can ask akonadi and in this case it looks like the synthesis engine will talk to and ask us. So I'm thinking in this latter case we need to see how the flow will be in details ... smth like a functional and/or sequence diagram in UML ... would be great. regards |
|
From: Chris F. <cd...@fo...> - 2011-12-06 21:49:23
|
On Fri, Dec 02, 2011 at 01:18:27AM +0100, deloptes wrote: > I think it fits better then we suspect, if I understood correctly what I > read. > 1) In OpenSync's plugin you have the main sync and the data sync(s). The > main sync will represent the UI API and the latter the datastore API. The > calls can be handled either by the opensync plugin or passed to the engine > and vice versa (depends what we want to achieve). This means > A)the opensync plugin will drive the engine in the main sync and provide the > transport etc. > B) The data syncs will cover the data store work (and will act as DB plugins > to the synthesis and object types to the opensync engine - i.e. contacts, > events and so on). > 2) Respective DevInf will be used/generated after or during both sides are > getting discovered/configured. > 3) If it is necessary for the synthesis engine to lead the sync, we can do > this against the opensync database as Chris suggested, and we will mark the > entries to know in which state they are (there is a mechanism in opensync > to do so). Hi deloptes, It almost sounds like you're planning to make one plugin that connects to both opensync and libsynthesis at the same time. Is that correct? That would be cool if you can swing it. :-) I don't think I'd worry about getting the classes correct just yet. I'd try writing just a skeleton framework, with maybe printf() statements following the logic, just as a simple proof of concept. Once we have such a framework, I can certainly look at it, and provide suggestions on a class hierarchy. Would that help? - Chris |
|
From: deloptes <del...@ya...> - 2012-02-12 16:52:46
|
deloptes wrote: > > So modified version of the previous plan: > > 1. initialize the plugin in the osync engine > 2. start the synthesis engine (UI) > 3. connect the phone or act as whatever SyncML client/server (DB? or UI?) > 4. sync (get changes etc) - provide a syncml plugin (DB) > 5. disconnect (DB? or UI?) > 6. stop the engine (UI) > 7. finalize the plugin in the osync engine > Hi, again, FYI: I am pretty occupied lately, but I am still working on this, so I was dealing with #1 and could initialize and open session on the engine. Now I am working on the discover part of the opensync plugin. I'm planning to do http-client/server first, so this is related to the client part. Here is some output from my code EKO: -------------------------------- EKO: bool OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*, OSyncPluginInfo*, OSyncError**) EKO: >> m_canConnect:1 EKO: >> m_canDisconnect:1 EKO: >> m_canCommit:0 EKO: >> m_canGetChanges:0 EKO: >> m_canWrite:0 EKO: >> m_canCommitAll:0 EKO: >> m_canRead:0 EKO: >> m_canSyncDone:0 EKO: >> m_canBatchCommit:0 EKO: virtual void OSynthML::SynthmlHttpClient::connect()connect to Synthesis name='synthml-sync' err=0 modu='synthml-sync' err=404 modu='synthml-sync.so' err=0 func err=0 'SySync_ConnectEngine' 00007F813C68F6C0 call err=0 EKO: (SyncMLCfgPath) bool OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*, OSyncPluginInfo*, OSyncError**)...../syncml-new/src/synthesis-client-conf.xml EKO: (InitEngineFile) bool OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*, OSyncPluginInfo*, OSyncError**) OK EKO: (OpenKeyByPath:profiles) bool OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*, OSyncPluginInfo*, OSyncError**) OK EKO: (OpenSession) bool OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*, OSyncPluginInfo*, OSyncError**) OK EKO: (CloseSession) bool OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*, OSyncPluginInfo*, OSyncError**) OK EKO: bool OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*, OSyncPluginInfo*, OSyncError**) DONE EKO: void* synthml_http_client_initialize(OSyncPlugin*, OSyncPluginInfo*, OSyncError**) OK EKO: void* synthml_http_client_initialize(OSyncPlugin*, OSyncPluginInfo*, OSyncError**) OSyncObjTypeSink#contact EKO: bool OSynthML::DataSink::initialize(OSyncPlugin*, OSyncPluginInfo*, OSyncObjTypeSink*, OSyncError**) initializing: contact EKO: virtual sysync::CVersion OSynthML_Adapter_Module::Version() EKO mVersion: 17301505 EKO: virtual sysync::TSyError OSynthML_Adapter_Module::Capabilities(char*&) EKO cCaps: PLATFORM:Linux DLL:true MANUFACTURER:OpenSync.org DESCRIPTION:OSynthML_AdapterOpenSync Plugin MINVERSION:V1.5.1.0 ADMIN_Info:yes ITEM_AS_KEY:yes EKO mPlugParams: test EKO: virtual sysync::sInt32 OSynthML_Adapter_Session::PasswordMode() EKO pw mode: 2 EKO: >> m_canConnect:0 EKO: >> m_canDisconnect:0 EKO: >> m_canCommit:1 EKO: >> m_canGetChanges:1 EKO: >> m_canWrite:0 EKO: >> m_canCommitAll:0 EKO: >> m_canRead:0 EKO: >> m_canSyncDone:1 EKO: >> m_canBatchCommit:0 EKO: bool OSynthML::DataSink::initialize(OSyncPlugin*, OSyncPluginInfo*, OSyncObjTypeSink*, OSyncError**) DONE EKO: void* synthml_http_client_initialize(OSyncPlugin*, OSyncPluginInfo*, OSyncError**) DONE EKO: osync_bool synthml_discover(OSynthML::SYNTHML_PLUGIN_TYPE, OSyncPluginInfo*, void*, OSyncError**)Plugtype OBEX, CLIENT, SERVER: 1 EKO: osync_bool OSynthML::SynthmlHttpClient::testSupport(OSyncObjTypeSink*, OSyncPluginConfig*, std::string, OSyncError**) EKO: osync_bool OSynthML::SynthmlHttpClient::testSupport(OSyncObjTypeSink*, OSyncPluginConfig*, std::string, OSyncError**) DevInf or similar asking the engine to provide information EKO: osync_bool OSynthML::SynthmlHttpClient::testSupport(OSyncObjTypeSink*, OSyncPluginConfig*, std::string, OSyncError**) foreach collection EKO: osync_bool OSynthML::SynthmlHttpClient::testSupport(OSyncObjTypeSink*, OSyncPluginConfig*, std::string, OSyncError**)> configure ressource EKO: osync_bool OSynthML::SynthmlHttpClient::testSupport(OSyncObjTypeSink*, OSyncPluginConfig*, std::string, OSyncError**)1 DONE EKO: void synthml_http_client_finalize(void*) START EKO: virtual void OSynthML::SynthmlHttpClient::disconnect() disconnect from Synthesis EKO: virtual void OSynthML::SynthmlHttpClient::disconnect() OK EKO: virtual void OSynthML::SynthmlHttpClient::disconnect()0 EKO: void synthml_http_client_finalize(void*) DONE Discovered Objtypes: contact Format: vcard21 Format: vcard30 Here is some log from the initialization. more /home/yoki/kde-testdir/osynctrace/sysynclib_uni_linux* *** Start of log ==== Client Session started with SyncML (Server+Client) Engine Version 3.4.0.27 ---- Hardcoded Product name: SySync SyncML Library OpenSource Linux ---- Configured Model/Manufacturer: SySync SyncML Library OpenSource Linux / Synthesis AG ---- Running on Linux, URI/deviceID='linux:lisa.s-und-s.home' ---- Platform Hardware Name/Version = 'Linux PC', Firmware/OS Version = 'unknown' ---- Configured Hardware Version = 'Linux PC', Firmware Version = 'unknown' ---- System local time : 2012-02-12 17:39:19.358 (time zone 'CET/CEST', offset 1:00 hours east of UTC) ---- System time in UTC : 2012-02-12 16:39:19.358 ==== Config file='/home/yoki/opensync/svn-source/libopensync-plugin-akonadi/syncml-new/src/synthesis-client-conf.xml', Last Change=2012-02-12 16:13:01.000 ==== Config ID string='OpenSync.org SyncML Client Engine >=3.4 config' ##### DBApi (LNK): Session_CreateContext: desc='Text database module. Writes data directly to TDB_*.txt file', vers=V1.8.0.0 ##### TextDB (LNK): Session_CreateContext: 18291952 '212195867959357' [2012-02-12 17:39:19.358] SessionAbort - Aborting Session, Status=20017, ProblemSource=LOCAL WARNING: Aborting Session with Reason Status 20017 (LOCAL problem) *** --------------- Ignoring all commands in this message (after 0 sec. request processing, 0 sec. total) with Status 20017 (0=none) from here on [2012-02-12 17:39:19.358] End of 'SessionAbort' ##### TextDB (LNK): Session_Logout: 18291952 ##### TextDB (LNK): Session_DeleteContext: 18291952 *** End of log |
|
From: Chris F. <cd...@fo...> - 2012-02-22 00:13:28
|
On Sun, Feb 12, 2012 at 05:52:19PM +0100, deloptes wrote: > Hi, again, > FYI: > I am pretty occupied lately, but I am still working on this, so I was > dealing with #1 and could initialize and open session on the engine. > Now I am working on the discover part of the opensync plugin. I'm planning > to do http-client/server first, so this is related to the client part. > > Here is some output from my code Looks like you're making progress... thanks for the update! - Chris |
|
From: Emanoil K. <del...@ya...> - 2012-02-22 18:10:28
|
Hi, thanks for encouragement. There are still few things that I don't understand and the other problem is that there is not enough time to read or work on it. Let me share what I'm trying to do and you or some one on the list can advise. I decided to go for following create syncml-http-server and syncml-http-client (in my design it's called synthml for synthesis). My idea is that I can use them communicate with each other before actually implementing an obex client for accessing the phone. Besides the modern phones provide http access, so in theory it should be possible to hook them to the server or client in opensync. And here comes the question: what does a syncml phone provide - is it a server or is it a client. The other question is what and how does the engine exactly do for the syncing: is it a piece able to speak syncml with a particular device in form of server and/or client or did I understand it wrong. My plan (and part of it is already coded) is to provide access to the engine via UI Api to make configuration and adjustments over the plugin possible and from the DB API for the data sync. How do you feel about it? Something I also do not understand from programming point of view I had a look into SyncEvo and there they use boosts shared pointers. So my question is under which circumstanses are you forced to do it - the name is somehow self explaining - but shared between what and why is something I don't understand also looking into my schedule for the future months it will take me some longer time for doing this. kind regards |
|
From: Chris F. <cd...@fo...> - 2012-02-22 23:58:50
|
On Wed, Feb 22, 2012 at 10:03:41AM -0800, Emanoil Kotsev wrote:
> My plan (and part of it is already coded) is to provide access to the engine via UI Api to make configuration and adjustments over the plugin possible and from the DB API for the data sync.
> How do you feel about it?
You're blazing a trail in new territory, so I would say that the code is
the important part. The more you code, the more details you'll uncover,
and eventually get to the point where it works. :-)
> Something I also do not understand from programming point of view
> I had a look into SyncEvo and there they use boosts shared pointers. So my question is under which circumstanses are you forced to do it - the name is somehow self explaining - but shared between what and why is something I don't understand
Boost shared pointers (or the shared pointers in the tr1 namespace, which
are the same), are for sharing pointers within the same application.
Smart pointers are designed so that you don't have to worry about when
to free an object. As soon as the pointer object goes out of scope, then
the object it points to is freed.
If you use std::auto_ptr<>, then only one auto_ptr object has a copy of
the pointer at a time.
auto_ptr<MyObject> ptr1 (new MyObject);
auto_ptr<MyObject> ptr2;
ptr2 = ptr1; // ptr1 is now null, and cannot be used
// only ptr2 is valid
You use auto_ptr when you only need one copy of a pointer at any given time.
Often when you're returning a pointer from a function.
auto_ptr<MyObject> FactoryFunction()
{
auto_ptr<MyObject> ptr;
// ... some hard work
return ptr;
}
With a shared_ptr, it keeps track of how many copies exist, and only frees
the real object when the last pointer disappears.
shared_ptr<MyObject> ptr1 (new MyObject);
shared_ptr<MyObject> ptr2;
ptr2 = ptr1; // both ptr1 and ptr2 are valid
So, in a real application, ptr1 might exist in one class, perhaps a list,
and ptr2 might exist in some other class. It doesn't matter which pointer
goes out of scope first. The last one to go out of scope will free the
object.
> also looking into my schedule for the future months it will take me some longer time for doing this.
That's ok. At least someone is working on it! :-)
- Chris
|
|
From: deloptes <del...@ya...> - 2011-12-06 22:58:45
|
Chris Frey wrote: > On Fri, Dec 02, 2011 at 01:18:27AM +0100, deloptes wrote: >> I think it fits better then we suspect, if I understood correctly what I >> read. >> 1) In OpenSync's plugin you have the main sync and the data sync(s). The >> main sync will represent the UI API and the latter the datastore API. The >> calls can be handled either by the opensync plugin or passed to the >> engine and vice versa (depends what we want to achieve). This means >> A)the opensync plugin will drive the engine in the main sync and provide >> the transport etc. >> B) The data syncs will cover the data store work (and will act as DB >> plugins to the synthesis and object types to the opensync engine - i.e. >> contacts, events and so on). >> 2) Respective DevInf will be used/generated after or during both sides >> are getting discovered/configured. >> 3) If it is necessary for the synthesis engine to lead the sync, we can >> do this against the opensync database as Chris suggested, and we will >> mark the entries to know in which state they are (there is a mechanism in >> opensync to do so). > > Hi deloptes, > > It almost sounds like you're planning to make one plugin that connects to > both opensync and libsynthesis at the same time. Is that correct? Yes, it will be an opensync plugin and i) will drive libsynthesis (thus follow the client/server UI logic) from the mainSink and ii) will provide DB plugins to the synthesis engine from the DataSink. I will have some opensync and synthesis related question on this, though the documentation in the synthesis project looks much better to me. If this does not work we'll probably need to write something like osynctool that will drive the synthesis engine from user perspective and interact with opensync accordingly - it's like plan B solution ;-) What I would like is to avoid unnecessary work as far as possible. > > That would be cool if you can swing it. :-) > > I don't think I'd worry about getting the classes correct just yet. > I'd try writing just a skeleton framework, with maybe printf() statements > following the logic, just as a simple proof of concept. Once we have > such a framework, I can certainly look at it, and provide suggestions > on a class hierarchy. > > Would that help? > Yes, this would be great. Unfortunately, I'm preoccupied with private and business stuff until around Christmass and I'm working occasionally on it mainly reading docs and drawing drafts from time to time. I prepared a Find...cmake file for libsynthesis and tried to compile empty classes to check if linking works and so. Lately I did research on the logic behind synthesis, so that I may think it could be theoretically doable - one way or another (plan B). However any effort with success will bring us to another level of opensync and make it usable at least for me. I have additional question. Though it might be very profitable to implement obex transport in terms of mobile phones, it might be more helpful for testing to implement http client/server. What do you think? So in sum the task of the project would be to make a prototype with empty calls that would use synthesis syncml over http server/client transport. It should be possible to configure them in pair for testing - correct? What about the licensing question - did you have a look into the libsynthesis licenses? regards |
|
From: Chris F. <cd...@fo...> - 2011-12-07 00:31:09
|
On Tue, Dec 06, 2011 at 11:58:19PM +0100, deloptes wrote: > I have additional question. Though it might be very profitable to implement > obex transport in terms of mobile phones, it might be more helpful for > testing to implement http client/server. What do you think? > > So in sum the task of the project would be to make a prototype with empty > calls that would use synthesis syncml over http server/client transport. > It should be possible to configure them in pair for testing - correct? I don't really know... Lukas? You reading this? :-) > What about the licensing question - did you have a look into the > libsynthesis licenses? There's no problem with libsynthesis licensing. It is LGPL. http://www.synthesis.ch/indefero/index.php/p/libsynthesis/source/tree/master/COPYING - Chris |
|
From: deloptes <del...@ya...> - 2011-12-09 09:31:19
|
Chris Frey wrote:
> I don't think I'd worry about getting the classes correct just yet.
> I'd try writing just a skeleton framework, with maybe printf() statements
> following the logic, just as a simple proof of concept. Once we have
> such a framework, I can certainly look at it, and provide suggestions
> on a class hierarchy.
OK, so here is something interesting to start with.
I've got the framework to compile and link. Also the basic opensync related
stuff. At this point I am not calling any synthesis functions as it needs
to be configured first ...
The lines prefixed with EKO: are of interest. I'll probably better use
__PRETTY_FUNCTION__ macro for this. Anyway, I was wondering why it is
calling "get_sync_info" that many times in the discover function ... is it
coming from the threads that are started?
Note that "EKO: connect to Synthesis" is coming from the
httpClientSink->connect() which is the mainSink and inheriting the
synthesis UI class.
"EKO: initializing: contact" is comming from the DataSink class that is
inheriting the DB API class
= osynctool --listplugins =
EKO: get_sync_info:
Available plugins:
synthml-obex-client
synthml-http-server
synthml-http-client
akonadi-sync
file-sync
evo2-sync
= osynctool --discover synth1 =
EKO: get_sync_info:
EKO: get_sync_info:
EKO: get_sync_info:
EKO: synthml_http_client_initialize
EKO: httpClientSink->initialize() DONE
EKO: connect to Synthesis
EKO: OSyncObjTypeSink#contact
EKO: initializing: contact
EKO: synthml_discover: 1
EKO: DevInf or similar asking the engine to provide information
EKO: foreach collection
EKO: configure ressource
EKO: synthml_http_client_finalize:
EKO: disconnect from Synthesis
EKO: synthml_http_client_finalize: DONE
Discovered Objtypes:
contact
Format: vcard21
Format: vcard30
EKO: get_sync_info:
EKO: get_sync_info:
Discovered Objtypes:
contact
Format: file
And something C/C++ related - where can I read about it, or can you answer
briefly here. there is this extern C {} block and inside I can use
std::cout << ...;
How is this all handled by the compiler and/or processor so that it works
from C. I would say it is the compiler that is doing the magic ... but I'm
too curious to know what actually happens. In the book it says briefly, it
is providing access to C++ functions from C.
I was reading this
http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html but got
confused in the middle.
regards
|
Thanks for helping keep SourceForge clean.
X