[SyncEvolution] SyncEvolution in Fremantle

[Patrick Ohly]

Hi!

This is becoming more SyncEvolution specific. Should we continue
cross-posting to maemo-developers?

On Sat, 2009-12-26 at 13:53 +0000, Ove Kaaven wrote:
> Patrick Ohly skrev:
> > I was planning to do a 0.9.2 update release in a few weeks. Should we
> > merge your code and include the Maemo support in the release
> > announcement?
> 
> If you want.

It's your call. Given that you raised some questions below about
improvements which cannot be done in backwards-compatible way between
releases of the calendar backend (change tracking!), it might be better
to give it some more time and release with 1.0 (tentative goal: end of
March).

> Is the debian/ dir in the sources maintained, anyway?

Not at the moment. It was used exclusively for the Maemo .deb, so feel
free to modify it.

> It's not clear from the website whether this "Linux Foundation license
> agreement" is really to be sent to the moblin guys, or to some other
> address.

My reading is that it needs to go to the Linux Foundation. I'll check.

>  (Presumably, syncevolution isn't part of moblin.)

Correct.

> > On Thu, 2009-12-24 at 08:03 +0000, Ove Kaaven wrote:
> >> via the Maemo-Calendar backend which I've
> >> spent the last two days writing
> > 
> > I'm glad to hear that you got this working without too much effort. Any
> > suggestions about improving the available documentation to make backend
> > development easier?
> 
> Not sure. I did find all the sync source stuff a bit confusing and badly
> documented.

I was hoping that TrackingSyncSource.h had enough information to be
useful, but you are right, it doesn't explain the big picture. A more
general introduction of "source", "item", etc. would be needed. Time to
resurrect Doxygen and write some additional pages, I suppose. Would that
have helped?

>  Especially since it's been years since I last programmed C++
> (I had started to agree with the C++ detractors, it's a *really* messy
> language, and it still remains the case that any C++ framework you
> didn't design yourself can be quite difficult to get into).

IMHO *any* framework is difficult to start with, regardless of the
language :-/

> I can't quite recall exactly what confused me the most as I wrote the
> backend, but there are still a few things I'm unsure of:
> 
> - I'm not sure how to properly write those integration tests in the
> *Register.cpp

I can add those when merging the code.

> - Do I need to worry about getSupportedTypes() or anything

You only need to implement the pure virtual methods, everything else has
reasonable defaults.

getSupportedTypes() is legacy code which was inherited from the Funambol
library. It became obsolete when moving to libsynthesis and is already
removed on "master" (well, almost - just found a copy of it in a derived
class). Funambol required that sources deal with data conversion
themselves, whereas with Synthesis this is done by the engine.

> - The Maemo's calendar-backend can return entries that have changed
> after a particular date (typically you'd use the time of the previous
> sync). Is there a way to use this to improve on the TrackingSyncSource
> method, so it won't be necessary to load and generate revision strings
> for the whole database every time?

As Congwu said, this can be done by inheriting from SyncSource directly
and adding the SyncSource* building blocks that you want to reuse. You
can use the TrackingSyncSource as an example how that is done.

The "time of last sync" is something that could be stored either in an
internal source property or (better) in the SyncML anchor string,
handled by the Synthesis engine. However, this will require changes to
the Synthesis/SyncEvolution and SyncSource interfaces. We have to work
on this anyway for resume support in the SyncML server, so my suggestion
is to address this in 1.0 like this:
      * make those API changes
      * create a new DateSyncSource which requires the following
        information from derived classes:
              * complete list of all local item IDs
              * list of changed item IDs since a certain time
      * change FileSyncSource so that it is derived from DateSyncSource

Do you have easy access to all IDs of existing items? This is necessary
to detect deleted items.

> - The Maemo addressbook (which is still ebook-based), as well as the
> calendar (which has APIs to convert to vcal 1.0 and ical 2.0),

Do you have a pointer to these APIs and perhaps the underlying source
code? I'm curious how the vCalendar 1.0 support is done.

>  stores
> some non-standard fields. I noticed something on the SyncEvolution
> webpage about mimeprofiles to specify what fields are stored locally. Is
> there a way to specify that, so that these fields are not destroyed on
> the Maemo device when syncing with a server that doesn't support them,
> even though the backends do convert from/to the standard vcard and ical
> formats?

This is already possible, but we aren't sure yet how to maintain the
different profiles. Right now, src/syncclient_sample_config.xml contains
a "contacts" field list (internal representation) and "vCard" profile
that is used both for the SyncML peer and the local backends, with some
tweaks to let some properties be handled differently on both sides
("EVOLUTION" rule).

If you are interested, then I suggest that you modify the .xml config
directly without caring about the effect on other backends. This is
something that we'll sort out when merging your changes.

> I did write the code so that if the URI is not prefixed with "id:", then
> it will try to look the calendar up by name.

The Evolution backends do the same thing.

>  Perhaps I could have used a
> "name:" prefix for that or something, but I wasn't sure what the best
> way was.

I thing your approach is the right one. That way users can use the name
as value for "evolutionsource" without having to learn a specific
syntax.

> But I did not write code to let you create a new calendar.
> Using file:// doesn't make sense since you can't give the
> calendar-backend a file path, that's not how it works.

Testing works without that, one just has to create calendars with a
suitable name first manually.

-- 
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.