Funambol C++ APIs
Overview <ul><li>Looking backward </li></ul><ul><li>Current status </li></ul><ul><li>Looking forward </li></ul><ul><li>Tes...
Once upon a time Looking backward (1) <ul><li>Funambol needed a client to show its server technology and a Java prototype ...
The API portability Looking backward (2) The API had been designed to be portable since  the  beginning. Client Sync APIs ...
The unexpected along the way Looking backward (3) <ul><li>... and along came the idea to sync emails and to push them </li...
Bottom line.... Looking backward (4) <ul><li>The original design did not accommodate all what was added along the way </li...
Funambol C++ APIs overview  Current Status (1) <ul><li>Funambol C++ APIs  </li></ul><ul><ul><li>DS engine (to synchronize ...
The how and the what Current status (2) <ul><li>The Sync Engine is data agnostic, any data can be transported/synchronized...
The how (1) Current status (3) SyncML Server   (choose your favorite open source one) Sync Engine Sync Source Back End
The how (2) Current status (4) Sync Engine Sync Source Server Authentication OK What changed? Changes Client changes Serve...
The what Current status (5) <ul><li>Typical data exchanged during synchronization </li></ul><ul><li>Contacts </li></ul><ul...
Push service Current status (6) <ul><li>Server to client push is implemented by an API module </li></ul>Heartbeat Notifica...
Portability Current status (7) <ul><li>Different patterns for portability </li></ul><ul><ul><li>One interface, different i...
Next easy steps Looking forward (1) <ul><li>Better modularization </li></ul><ul><ul><li>no monolithic API but components t...
Next steps (longer term) Looking forward (2) <ul><li>Data model pushed into the API </li></ul><ul><ul><li>There is no comm...
Data model into the API Looking forward (3) PIMItem ContactItem EventItem TaskItem Standard format parsers and formatters ...
Use of standard containers Looking forward (4) <ul><li>STL would be perfect if it were available on Symbian :( </li></ul><...
The wrapping route Looking forward (5) With STL support With QT support And if no good containers are available, we can re...
One drawback of portability Testing the API (1) <ul><li>One code base, multiple platforms </li></ul><ul><ul><li>change her...
Testing frameworks Testing the API (2) <ul><li>Unit testing </li></ul><ul><ul><li>we are still learning the approach.. </l...
Unit testing on existing code Testing the API (3) <ul><li>Adding test code is tedious, but sometimes also very hard </li><...
Integration tests Testing the API (4) <ul><li>Require a sync source and possibly a server </li></ul><ul><ul><ul><li>The AP...
Our continuum environment Testing the API (5) <ul><li>We build the API every night as part of our continuum environment </...
How to contribute <ul><li>There are several ways to contribute </li></ul><ul><ul><li>help us to extend the APIs </li></ul>...
The End (Q&A?)
Upcoming SlideShare
Loading in …5
×

Funambol C++ API

2,319 views

Published on

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,319
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
67
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Funambol C++ API

  1. 1. Funambol C++ APIs
  2. 2. Overview <ul><li>Looking backward </li></ul><ul><li>Current status </li></ul><ul><li>Looking forward </li></ul><ul><li>Testing the APIs </li></ul><ul><li>Q&A </li></ul>
  3. 3. Once upon a time Looking backward (1) <ul><li>Funambol needed a client to show its server technology and a Java prototype has born </li></ul><ul><li>Supporting Windows platforms required clients for Outlook written in C++ </li></ul><ul><li>The clients have been built on top of a common set of API, to share the protocol implementation. </li></ul>
  4. 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. 5. The unexpected along the way Looking backward (3) <ul><li>... and along came the idea to sync emails and to push them </li></ul><ul><li>... and along came (and fortunately went away) Palm OS </li></ul><ul><li>... and along came SyncEvolution and the Posix support </li></ul><ul><li>... and along came the iPhone and the Mac </li></ul><ul><li>... and along came Symbian </li></ul>
  6. 6. Bottom line.... Looking backward (4) <ul><li>The original design did not accommodate all what was added along the way </li></ul><ul><li>Each platform/feature introduced new constrains </li></ul><ul><li>If you see something strange in the APIs don't worry. Everything made sense at some point in time :) </li></ul>
  7. 7. Funambol C++ APIs overview Current Status (1) <ul><li>Funambol C++ APIs </li></ul><ul><ul><li>DS engine (to synchronize data) </li></ul></ul><ul><ul><li>DM partial support (just the storage tree) </li></ul></ul><ul><ul><li>Push technology (to receive push notifications) </li></ul></ul><ul><li>Supported platforms </li></ul><ul><ul><li>Windows and Windows mobile </li></ul></ul><ul><ul><li>Posix (but mostly Linux) </li></ul></ul><ul><ul><li>iPhone and Mac </li></ul></ul><ul><ul><li>Symbian (>= 9.1) </li></ul></ul>
  8. 8. The how and the what Current status (2) <ul><li>The Sync Engine is data agnostic, any data can be transported/synchronized (the how) </li></ul><ul><li>Each client provides access to data, relying on its knowledge of the data and of the underlying system (the what) </li></ul>
  9. 9. The how (1) Current status (3) SyncML Server (choose your favorite open source one) Sync Engine Sync Source Back End
  10. 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. 11. The what Current status (5) <ul><li>Typical data exchanged during synchronization </li></ul><ul><li>Contacts </li></ul><ul><li>Events/Tasks </li></ul><ul><li>Notes </li></ul><ul><li>Emails </li></ul><ul><li>Files </li></ul>
  12. 12. Push service Current status (6) <ul><li>Server to client push is implemented by an API module </li></ul>Heartbeat Notifications Notifications Push Server Client Push module
  13. 13. Portability Current status (7) <ul><li>Different patterns for portability </li></ul><ul><ul><li>One interface, different implementations </li></ul></ul><ul><ul><li>ifdefs in the code </li></ul></ul><ul><ul><li>Object factories </li></ul></ul><ul><li>We do a case by case choice based on what makes more sense </li></ul>
  14. 14. Next easy steps Looking forward (1) <ul><li>Better modularization </li></ul><ul><ul><li>no monolithic API but components that can be enabled/disabled </li></ul></ul><ul><ul><li>improved platform abstraction layer </li></ul></ul><ul><li>New components </li></ul><ul><ul><li>Updater to check for new versions </li></ul></ul>
  15. 15. Next steps (longer term) Looking forward (2) <ul><li>Data model pushed into the API </li></ul><ul><ul><li>There is no common model for most PIM data today. </li></ul></ul><ul><li>Use of standard containers </li></ul><ul><ul><li>STL? QT? Wrapping around them? </li></ul></ul><ul><li>Unified build system </li></ul><ul><ul><li>Cmake could be one solution. </li></ul></ul><ul><li>Improved large object support </li></ul><ul><ul><li>We need an option to avoid assembling/disassembling LO in memory </li></ul></ul>
  16. 16. Data model into the API Looking forward (3) PIMItem ContactItem EventItem TaskItem Standard format parsers and formatters PIMSyncSource BackEnd Interface (client code)
  17. 17. Use of standard containers Looking forward (4) <ul><li>STL would be perfect if it were available on Symbian :( </li></ul><ul><li>QT would be perfect if it were available on iPhone :( </li></ul><ul><li>What about the wrapping route? </li></ul>
  18. 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. 19. One drawback of portability Testing the API (1) <ul><li>One code base, multiple platforms </li></ul><ul><ul><li>change here, you break there! </li></ul></ul><ul><ul><li>You cannot test all the platforms... </li></ul></ul><ul><li>We test on the platform we are developing for and... </li></ul><ul><ul><li>rely on automatic tests for other platforms </li></ul></ul><ul><ul><li>rely on different levels of testing </li></ul></ul>
  20. 20. Testing frameworks Testing the API (2) <ul><li>Unit testing </li></ul><ul><ul><li>we are still learning the approach.. </li></ul></ul><ul><ul><ul><li>design interface, write the test, code </li></ul></ul></ul><ul><ul><li>we have a large code base without tests </li></ul></ul><ul><ul><ul><li>it is painful to make it testable </li></ul></ul></ul>
  21. 21. Unit testing on existing code Testing the API (3) <ul><li>Adding test code is tedious, but sometimes also very hard </li></ul><ul><li>How do we test big methods that (for example) require communications with the server? </li></ul><ul><li>How do we test classes with a very simple public interface but a lot of private code? </li></ul><ul><li>If someone has experiences to report.... </li></ul>
  22. 22. Integration tests Testing the API (4) <ul><li>Require a sync source and possibly a server </li></ul><ul><ul><ul><li>The APIs provide a File Sync source that can be used for this </li></ul></ul></ul><ul><ul><ul><li>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. </li></ul></ul></ul>
  23. 23. Our continuum environment Testing the API (5) <ul><li>We build the API every night as part of our continuum environment </li></ul><ul><li>We build all different variants </li></ul><ul><li>We run tests on windows and linux </li></ul><ul><li>On linux we use valgrind to automatically report memory leaks </li></ul>
  24. 24. How to contribute <ul><li>There are several ways to contribute </li></ul><ul><ul><li>help us to extend the APIs </li></ul></ul><ul><ul><li>use the APIs in your own client </li></ul></ul><ul><ul><li>port the APIs to any platform </li></ul></ul><ul><ul><li>help us to make the APIs more unit testable </li></ul></ul>
  25. 25. The End (Q&A?)

×