The document provides an overview of the Funambol C++ APIs for synchronization. It discusses the current status of the APIs, including supported platforms and features. It also looks forward to potential improvements, such as better modularization, a common data model, and improved testing. The goal is to make the APIs more portable, extensible and testable across multiple platforms.

1. Funambol C++ APIs

2. Overview Looking backward Current status Looking forward Testing the APIs Q&A

3. Once upon a time Looking backward (1) Funambol needed a client to show its server technology and a Java prototype has born Supporting Windows platforms required clients for Outlook written in C++ The clients have been built on top of a common set of API, to share the protocol implementation.

4. The API portability Looking backward (2) The API had been designed to be portable since the beginning. Client Sync APIs OS and native data access

5. The unexpected along the way Looking backward (3) ... and along came the idea to sync emails and to push them ... and along came (and fortunately went away) Palm OS ... and along came SyncEvolution and the Posix support ... and along came the iPhone and the Mac ... and along came Symbian

6. Bottom line.... Looking backward (4) The original design did not accommodate all what was added along the way Each platform/feature introduced new constrains If you see something strange in the APIs don't worry. Everything made sense at some point in time :)

7. Funambol C++ APIs overview Current Status (1) Funambol C++ APIs DS engine (to synchronize data) DM partial support (just the storage tree) Push technology (to receive push notifications) Supported platforms Windows and Windows mobile Posix (but mostly Linux) iPhone and Mac Symbian (>= 9.1)

8. The how and the what Current status (2) The Sync Engine is data agnostic, any data can be transported/synchronized (the how) Each client provides access to data, relying on its knowledge of the data and of the underlying system (the what)

9. The how (1) Current status (3) SyncML Server (choose your favorite open source one) Sync Engine Sync Source Back End

10. The how (2) Current status (4) Sync Engine Sync Source Server Authentication OK What changed? Changes Client changes Server changes .. Black magic. . Apply changes Result Result

11. The what Current status (5) Typical data exchanged during synchronization Contacts Events/Tasks Notes Emails Files

12. Push service Current status (6) Server to client push is implemented by an API module Heartbeat Notifications Notifications Push Server Client Push module

13. Portability Current status (7) Different patterns for portability One interface, different implementations ifdefs in the code Object factories We do a case by case choice based on what makes more sense

14. Next easy steps Looking forward (1) Better modularization no monolithic API but components that can be enabled/disabled improved platform abstraction layer New components Updater to check for new versions

15. Next steps (longer term) Looking forward (2) Data model pushed into the API There is no common model for most PIM data today. Use of standard containers STL? QT? Wrapping around them? Unified build system Cmake could be one solution. Improved large object support We need an option to avoid assembling/disassembling LO in memory

16. Data model into the API Looking forward (3) PIMItem ContactItem EventItem TaskItem Standard format parsers and formatters PIMSyncSource BackEnd Interface (client code)

17. Use of standard containers Looking forward (4) STL would be perfect if it were available on Symbian :( QT would be perfect if it were available on iPhone :( What about the wrapping route?

18. The wrapping route Looking forward (5) With STL support With QT support And if no good containers are available, we can revert to the ones we have today (safety net) Template <T> Funambol::list<T> { std::list<T> stlList; void append(<T> item) { stlList.append(item); } } Template <T> Funambol::list<T> { QList<T> qtList; append(<T> item) { qtList.append(item); } }

19. One drawback of portability Testing the API (1) One code base, multiple platforms change here, you break there! You cannot test all the platforms... We test on the platform we are developing for and... rely on automatic tests for other platforms rely on different levels of testing

20. Testing frameworks Testing the API (2) Unit testing we are still learning the approach.. design interface, write the test, code we have a large code base without tests it is painful to make it testable

21. Unit testing on existing code Testing the API (3) Adding test code is tedious, but sometimes also very hard How do we test big methods that (for example) require communications with the server? How do we test classes with a very simple public interface but a lot of private code? If someone has experiences to report....

22. Integration tests Testing the API (4) Require a sync source and possibly a server The APIs provide a File Sync source that can be used for this Complex tests simulating synchronization are part of the API testing framework. It would be nice to have a higher definition language to specify a test.

23. Our continuum environment Testing the API (5) We build the API every night as part of our continuum environment We build all different variants We run tests on windows and linux On linux we use valgrind to automatically report memory leaks

24. How to contribute There are several ways to contribute help us to extend the APIs use the APIs in your own client port the APIs to any platform help us to make the APIs more unit testable

25. The End (Q&A?)