From patrick.ohly at gmx.de Mon Aug 24 15:08:37 2009 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Mon, 24 Aug 2009 17:08:37 +0200 Subject: SyncML-Klient KDE In-Reply-To: <200908231615.34457.sasch.pe@gmx.de> References: <1251031180.5911.26.camel@localhost> <200908231615.34457.sasch.pe@gmx.de> Message-ID: <1251126506.16183.106.camel@pohly-mobl1.ikn.intel.com> Hello Sascha! Let's switch to English as you suggested, with the mailing lists on CC. I've summarized the main points below. For those joining the discussion, I mailed Sascha after I read about his KDE SyncML work and introduced SyncEvolution+libsynthesis. Some relevant links: http://syncevolution.org/ http://moblin.org/documentation/syncevolution/direct-synchronization-aka-syncml-server As you said, libsynthesis wasn't available when you started your work on the KDE SyncML client/server. It's a real pity that we (Synthesis.ch for libsynthesis, Intel for the revampled SyncEvolution) couldn't get the open sourcing done sooner. On the other hand, this way you and the other SyncML projects which seem to happen this summer had a chance to experiment with the technology. That might make it easier to understand what libsynthesis and SyncEvolution are about. Regarding "libfunambol is good enough for a client": yes, after all I used it for over three years. But it has its limitations. In addition to the obvious lack of WBXML support (required for Google), you'll also find that the "pass KDE data to SyncML server directly" approach is too limited once you start doing interoperability testing with SyncML servers. I already mentioned vCalendar 1.0 support (mobical.net) and vCard extensions (X-SPOUSE); this is trivial to solve with libsynthesis and harder with libfunambol. But I'd like to go one step further: instead of switching to libsynthesis, I suggest that you consider integrating your work with SyncEvolution. libsynthesis is really just the raw engine. The app framework that you know from libfunambol is provided by SyncEvolution for libsynthesis. The "syncevolution" command line tool should work with a KDE backend right away. We are currently in the process of revising the D-Bus API for GUIs. The sync engine is already decoupled from the GTK GUI via D-Bus, but this was done in a rather ad-hoc fashion and we think this can be improved. It would be great to get your feedback, but as you are going on vacation (lucky you!), we'll have to give it a shot and then revise it when you come back end of September - assuming that you are interested, of course. -- Bye, Patrick Ohly -- Patrick.Ohly at gmx.de http://www.estamos.de/ From mike at mikearthur.co.uk Mon Aug 24 15:15:35 2009 From: mike at mikearthur.co.uk (Mike Arthur) Date: Mon, 24 Aug 2009 16:15:35 +0100 Subject: [Kde-pim] SyncML-Klient KDE In-Reply-To: <1251126506.16183.106.camel@pohly-mobl1.ikn.intel.com> References: <1251031180.5911.26.camel@localhost> <200908231615.34457.sasch.pe@gmx.de> <1251126506.16183.106.camel@pohly-mobl1.ikn.intel.com> Message-ID: <200908241615.35703.mike@mikearthur.co.uk> On Monday 24 August 2009 16:08:26 Patrick Ohly wrote: > But I'd like to go one step further: instead of switching to > libsynthesis, I suggest that you consider integrating your work with > SyncEvolution. libsynthesis is really just the raw engine. The app > framework that you know from libfunambol is provided by SyncEvolution > for libsynthesis. The "syncevolution" command line tool should work with > a KDE backend right away. > > We are currently in the process of revising the D-Bus API for GUIs. The > sync engine is already decoupled from the GTK GUI via D-Bus, but this > was done in a rather ad-hoc fashion and we think this can be improved. > It would be great to get your feedback, but as you are going on vacation > (lucky you!), we'll have to give it a shot and then revise it when you > come back end of September - assuming that you are interested, of > course. Out of interest, what are the dependencies for libsynthesis and syncevolution? -- Cheers, Mike Arthur http://mikearthur.co.uk/ From patrick.ohly at gmx.de Fri Aug 7 13:09:19 2009 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Fri, 07 Aug 2009 15:09:19 +0200 Subject: D-Bus bindings: C++ or C? Message-ID: <1249650556.9029.66.camel@pohly-mobl1.ikn.intel.com> Hello! I'm having second thoughts about the decision that Jussi and I made back in January about using dbus-glib as the main interface to D-Bus in the syncevo-dbus-server. The main rationale at that time was that it is readily available and a known quantity. However, after looking at some of the code that Jussi had to write to make our C++ classes work as part of a D-Bus server I'm wondering whether this advantage of dbus-glib is really worth it. Much of it is manually written glue code between dbus-glib/GObject and C++. I bet it would be a lot easier to solve this problem with dbus-c++. Except that it isn't part of most (all?) distros and much of the development takes place outside of the main project, with no recent official release... Another problem is lack or insufficient support for asynchronous method calls. Some branches of dbus-c++ might have it. This would be a deal-breaker, because we need that feature. So anyway, here's my question to Jussi: how much work is it really to implement the D-Bus API? Question to packagers: would you mind if we bundled a version of dbus-c++ with our source until some official release makes it into the distros? Any other alternatives? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From bremner at unb.ca Fri Aug 7 13:25:23 2009 From: bremner at unb.ca (David Bremner) Date: Fri, 07 Aug 2009 10:25:23 -0300 Subject: D-Bus bindings: C++ or C? In-Reply-To: <1249650556.9029.66.camel@pohly-mobl1.ikn.intel.com> References: <1249650556.9029.66.camel@pohly-mobl1.ikn.intel.com> Message-ID: <87my6bzrgc.wl%bremner@pivot.cs.unb.ca> At Fri, 07 Aug 2009 15:09:16 +0200, Patrick Ohly wrote: > > Question to packagers: would you mind if we bundled a version of > dbus-c++ with our source until some official release makes it into the > distros? > dbus++ is in the NEW queue for debian, so it should be in the unstable distribution in a couple of weeks (unless some licensing issue turns up, but I think the guy packaging it is pretty conscientious that way. So, you could bundle it, but I probably wouldn't use the bundled copy. Bundling is only extra disk space from debian point of view, unless there are licensing issues. Of course, hopefully the package compiles ok with the non-bundled version. David From patrick.ohly at gmx.de Fri Aug 7 13:45:38 2009 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Fri, 07 Aug 2009 15:45:38 +0200 Subject: [SyncEvolution] D-Bus bindings: C++ or C? In-Reply-To: <87my6bzrgc.wl%bremner@pivot.cs.unb.ca> References: <1249650556.9029.66.camel@pohly-mobl1.ikn.intel.com> <87my6bzrgc.wl%bremner@pivot.cs.unb.ca> Message-ID: <1249652735.9029.79.camel@pohly-mobl1.ikn.intel.com> Hello Robert! We are wondering whether using dbus-c++ in SyncEvolution is viable. David pointed out that you are packaging it for Debian. I found it in the NEW queue, as David said: http://ftp-master.debian.org/new/dbus-c++_0~20090718-1.html Can you clarify from which git repo you pull the sources? The "official" one on freedesktop.org or the one on gitorious? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From marcel at holtmann.org Fri Aug 7 14:41:39 2009 From: marcel at holtmann.org (Marcel Holtmann) Date: Fri, 07 Aug 2009 07:41:39 -0700 Subject: [SyncEvolution] D-Bus bindings: C++ or C? In-Reply-To: <1249650556.9029.66.camel@pohly-mobl1.ikn.intel.com> References: <1249650556.9029.66.camel@pohly-mobl1.ikn.intel.com> Message-ID: <1249656099.30166.5.camel@localhost.localdomain> Hi Patrick, > I'm having second thoughts about the decision that Jussi and I made back > in January about using dbus-glib as the main interface to D-Bus in the > syncevo-dbus-server. The main rationale at that time was that it is > readily available and a known quantity. > > However, after looking at some of the code that Jussi had to write to > make our C++ classes work as part of a D-Bus server I'm wondering > whether this advantage of dbus-glib is really worth it. Much of it is > manually written glue code between dbus-glib/GObject and C++. inside BlueZ, ConnMan, oFono etc. we are using libgdbus which is a nice and small helper library for writing D-Bus servers in C without any big extra bloat. We even duplicate the source in all projects to make it simpler for packages and integrators. I am not saying that this is the right solution for you, but you asked ;) Regards Marcel From jku at linux.intel.com Fri Aug 14 07:43:57 2009 From: jku at linux.intel.com (Jussi Kukkonen) Date: Fri, 14 Aug 2009 10:43:57 +0300 Subject: [SyncEvolution] D-Bus bindings: C++ or C? In-Reply-To: <1249656099.30166.5.camel@localhost.localdomain> References: <1249650556.9029.66.camel@pohly-mobl1.ikn.intel.com> <1249656099.30166.5.camel@localhost.localdomain> Message-ID: <4A8515BD.4000900@linux.intel.com> Marcel Holtmann wrote: > Hi Patrick, > >> I'm having second thoughts about the decision that Jussi and I made back >> in January about using dbus-glib as the main interface to D-Bus in the >> syncevo-dbus-server. The main rationale at that time was that it is >> readily available and a known quantity. >> >> However, after looking at some of the code that Jussi had to write to >> make our C++ classes work as part of a D-Bus server I'm wondering >> whether this advantage of dbus-glib is really worth it. Much of it is >> manually written glue code between dbus-glib/GObject and C++. Partial reason for the large amount of code was the decision to make the client side a C library. I notice that Josh has just backtracked his similar decision in carrick/gconnman because of the reasons you stated... On the other hand, the client code is pretty nice when using the library. I had two concerns with dbus-c++ then (and I guess I still do): 1. maintenance: there are at least three forks right now and it seems at least two are quite incompatible. 2. completeness/reliability, My expertise in C++ or (or D-Bus) is not deep enough to evaluate how complete or tested these bindings are. > inside BlueZ, ConnMan, oFono etc. we are using libgdbus which is a nice > and small helper library for writing D-Bus servers in C without any big > extra bloat. We even duplicate the source in all projects to make it > simpler for packages and integrators. I am not saying that this is the > right solution for you, but you asked ;) Thanks, that may make sense. It's just that dbus-glib was a known evil for me at the time... I've looked at connman and gdbus does look like a nice and clean API at least from server POV. However, I have to point out that from my GTK+ application POV a syncevolution-dbus-abstraction gobject is not bloat, it's a feature. - Jussi From rpurdie at rpsys.net Mon Aug 10 21:09:08 2009 From: rpurdie at rpsys.net (Richard Purdie) Date: Mon, 10 Aug 2009 22:09:08 +0100 Subject: D-Bus bindings: C++ or C? In-Reply-To: <1249650556.9029.66.camel@pohly-mobl1.ikn.intel.com> References: <1249650556.9029.66.camel@pohly-mobl1.ikn.intel.com> Message-ID: <1249938548.22268.187.camel@dax.rpnet.com> On Fri, 2009-08-07 at 15:09 +0200, Patrick Ohly wrote: > Question to packagers: would you mind if we bundled a version of > dbus-c++ with our source until some official release makes it into the > distros? >>From my point of view its unlikely to be a problem. I generally dislike and don't use bundled sources though and would add a git build from a git snapshot for dbus-c++. Cheers, Richard From Bob.Eggers at palm.com Mon Aug 3 13:32:45 2009 From: Bob.Eggers at palm.com (Bob Eggers) Date: Mon, 3 Aug 2009 06:32:45 -0700 Subject: SyncEvolution In-Reply-To: <1249212379.21963.45.camel@pohly-MOBL> References: <460216361116404BB61933403540E1698433EA04D1@ushqwmb03.palm1.palmone.com>,<1249212379.21963.45.camel@pohly-MOBL> Message-ID: <460216361116404BB61933403540E1698433EA04D3@ushqwmb03.palm1.palmone.com> Hi Patrick, I have a few questions aimed at trying to understand what I see in the backend code samples. I've been looking at SyncEvolution 0.8, because I assumed it was more stable at this point in time. Anyway, my questions are a mix of my possibly false assumptions and actual questions: 1) In the backend, are all the uid parameters local UID's? Need we have any concern about mapping to remote ID? Is the engine handling that? 2) listAllItems(): the backend itemizes the entire local store and set revisions[] with last revision stamp or modification time. 3) a) createItem(): generate a sync item data blob to ship to the server, which could be for add or update and we don't need to know? b) insertItem(): either update or add item to the local store depending on whether UID already exists locally? c) deleteitem(): delete item from the local store Does the sync engine handle deleting items on server based on the results of listAllItems (UID's detected missing)? 4) Our contacts records do not have a last mod time a) we are able to get a list of records that changed and another list of records deleted since last time we checked b) if my assumption that items not appearing in the listAllItems will be deleted remotely by the engine, we can ignore this deleted list c) with the changed records list, we could say last mod time is NOW (say, the start of sync), and set a custom field in the record to act as last mod time. (Will have to re-save the record locally.) d) with unchanged records, do nothing but extract that last mod time from the custom field 5) exportData walks through all records and create item data blobs - presumably this is called in the slow sync scenario? I appreciate your help - maybe these questions have been answered somewhere already. :) Bob Eggers ________________________________________ From: Patrick Ohly [patrick.ohly at gmx.de] Sent: Sunday, August 02, 2009 7:26 AM To: Bob Eggers Subject: Re: SyncEvolution On Fri, 2009-07-31 at 08:51 -0700, Bob Eggers wrote: > I am looking at using the Posix build of SyncEvolution to support a > contacts client on the Palm webOS. I've been getting familiar with > SyncML concepts and have looked at a few engines. I like SyncEvolution > because of the WBXML support in particular. You've mentioned Funambol and WBXML support in the same email - just to be sure that there are no misunderstandings, you are aware of SyncEvolution 0.9 using the Synthesis SyncML Engine? It no longer depends on Funambol source code or libraries at all. > One thing I'm struggling with is "getting it". I know I'm not the > first because I saw a just such a comment today in a Funambol slide > slow. The docs are generally sketchy, as you know, and the naming > conventions they used were not always the clearest. I might have inherited some of that in SyncEvolution :-/ > I have been studying backends that last couple of days trying to size > up our task. I wonder if you might field a handful of questions from > me? If so, let me know. Sure, just go ahead. However, if you don't mind, can we have that discussion on the SyncEvolution mailing list (syncevolution at syncevolution.org)? Don't worry about subscribing (unless you want to, of course), just mail me with that list on CC and I'll make sure that all your emails get through. That way answers will be available for others later on; the other SyncEvolution developers might also be able to help. -- Bye, Patrick Ohly -- Patrick.Ohly at gmx.de http://www.estamos.de/