On Mon, 2009-08-24 at 03:15 +0100, Chen, Congwu wrote:
> Hi, 
> I have a task to write a "How-to tutorial" for SyncEvolution[1] as
> part of the moblin-sdk program[2].

Excellent! Is this something which can co-publish on syncevolution.org?

>  I found the blog article "SyncML Client Do-It-Yourself Style" [2]
> written by Patrick fits this quite well. I will probably adapt this a
> little to fit into SyncEvolution 0.9 API. 
> Does anyone has suggestions on this?

I think we should replace the 0.9 backend API as soon as possible. In
other words, review and merge the backend-api into master, then after a
short testing/release cycle release 0.9.1 as replacement for 0.9. This
should include everything that was held back during the feature freeze
for 0.9 (message resend!). A revised GUI D-Bus interface would be nice
too, but is risky.

The "do-it-yourself" guide is indeed a good starting point. There is one
major limitation: the guide and the underlying code + make rules are
designed for people who want to build their own SyncEvolution tailored
for their own backends. Backends are not truly plugable.

The changes necessary to fix this are a bit intrusive, but not
particularly risky:
      * install libsyncevolution header files in a standard
        path: /usr/include/syncevolution/*.h
      * change the #include rules inside these .h files so that they use
        "syncevolution/" as prefix for all of them, rename "core"
        directory to "syncevolution"
      * don't depend on config.h in the header files (apps might not
        have the same defines in their own config.h)
      * install libsyncevolution.la and add a .pc file for it
      * scan a directory for backends to open dynamically in
        SyncSource.cpp instead of using a hard-coded list (should also
        work when running inside the build directory, with backends in
        backends/*/.libs)

Is this something that you could do in combination with updating the
guide?

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


_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to