Development Information
SVN Logs
* Created the zdtm_adw_msg.h and zdtm_adw_msg.c source files and implemented a structure to represent ADW messages as well as a function to parse raw ADW message content into a ADW message content structure. Beyond that, I defined the ADW_MSG_TYPE constant so that it can be used for message type identification and comparison. * Modified the zdtm_message_body structures zdtm_spec_type_content union by adding in instance of the zdtm_adw_msg_content structure called 'adw' to it so that the message body structure could be used to represent an ADW message body. I also modified the _zdtm_parse_raw_msg() function so that it parses raw ADW messages using the newly created zdtm_parse_raw_adw_msg() function.
* Fixed a bug in the zdtm_adr_msg.c file that was causing a segfault in the zdtm_parse_raw_adr_msg() function. Specifically it was a problem with the fact that the num_params was being interpreted as a uint32_t when it should have only been interpreted as a uint16_t. Hence, when the buf pointer was incremeneted by uint32_t it was incremented 2 bytes too far. * Implemented the zdtm_obtain_sync_id_lists() function in the zdtm_sync.h and zdtm_sync.c files respectively and documented it so that it could be used through the general API. * Modified zdtm_test_daemon.c to use zdtm_obtain_sync_id_lists() rather than _zdtm_obtain_sync_id_lists(). * Moved the _zdtm_obtain_sync_id_lists() function to zdtm_sync.h and zdtm_sync.c and renamed it zdtm_obtain_sync_id_lists() so that there was no extra wrapper layer for that function. * Moved the _zdtm_obtain_todo_item() function from zdtm_proto.h and zdtm_proto.c to zdtm_sync.h and zdtm_sync.c and renamed it zdtm_obtain_todo_item() so that there was no need for an extra wrapper layer to make it part of the general API. * Moved the _zdtm_obtain_calendar_item() function from zdtm_proto.h and zdtm_proto.c to zdtm_sync.h and zdtm_sync.c and renamed it zdtm_obtain_calendar_item() so that there was no need for an extra wrapper layer to make it part of the general API. * Moved the _zdtm_obtain_address_item() function from zdtm_proto.h and zdtm_proto.c to zdtm_sync.h and zdtm_sync.c and renamed it zdtm_obtain_address_item() so that there was no need for an extra wrapper layer to make it part of the general API. * Moved the _zdtm_delete_item() function from zdtm_proto.h and zdtm_proto.c to zdtm_sync.h and zdtm_sync.c and renamed it zdtm_delete_item() so that there was no need for an extra wrapper lapyer to make it part of the general API.
* Moved the standard sync stuff from the zdtm_test_daemon.c into the standard libraries public API specifically in the zdtm_initiate_sync() function. I also modified the the zdtm_test_daemon.c file and removed what should now be unnecessary code.
* Implemented the zdtm_address_item structure in zdtm_common.h to represent an address book item. * Implemented the _zdtm_parse_address_item_params() function in the zdtm_proto.h and zdtm_proto.c files respectively. I also documented the _zdtm_parse_address_item_params() function in the zdtm_proto.h file. * Implemented the _zdtm_obtain_address_item() function in the zdtm_proto.h and zdtm_proto.c files respectively. I also documented the _zdtm_obtain_address_item() function in the zdtm_proto.h file. * Implemented the _zdtm_free_params() function in the zdtm_proto.h and zdtm_prot.c files respectively. I also documented the _zdtm_free_params() function in the zdtm_proto.h file. * Modified the _zdtm_obtain_todo_item(), _zdtm_obtain_calendar_item(), and _zdtm_obtain_address_item() functions to use the _zdtm_free_params() function to free the params array allocated by their calls to _zdtm_obatain_item(). * Updated docs/lib_zdtm_sync_detailed_plan.planner and docs/lib_zdtm_sync_detailed_plan.html to reflect the addition of the _zdtm_parse_address_item_params() and _zdtm_obtain_address_item() functions.
* Implemented the zdtm_calendar_item structure in zdtm_common.h to represent calendar items. * Implemented the _zdtm_parse_calendar_item_params() function in the zdtm_proto.h and zdtm_proto.c files respectively. I also documented the _zdtm_parse_calendar_item_params() function in the zdtm_proto.h file. * Implemented the _zdtm_obtain_calendar_item() function in the zdtm_proto.h and zdtm_proto.c files respectively. I also documented the _zdtm_obtain_calendar_item() function in the zdtm_proto.h file. * Renamed the zdtm_todo structure to zdtm_todo_item structure to better identify what it represents and modified the appropriate code and documentation that was effected. * Updated docs/lib_zdtm_sync_detailed_plan.planner and docs/lib_zdtm_sync_detailed_plan.html to reflect the addition of the _zdtm_parse_calendar_item_params() and _zdtm_obtain_calendar_item() functions.
* Updated all the Copyright notices at the top of the files to be correct for GPL and added to the files which were missing a Copyright notice. * Implemented the _zdtm_delete_item() function in the zdtm_proto.h and zdtm_proto.c files respectively. I also documented the _zdtm_delete_item() function in the zdtm_proto.h file. * Updated docs/lib_zdtm_sync_detailed_plan.planner and docs/lib_zdtm_sync_detailed_plan.html to reflect the addition of the _zdtm_delete_item() function.
* Updated the html version of the lib_zdtm_sync detailed plan to reflect Rob's addition of the RSS Message and the reset_item_state function.
* Modified the lib_zdtm_sync_detailed_plan.planner file to reflect Rob's work today.
* Added the RSS message functions to the _zdtm_prepare_message() function so that it was built properly before sending it. * Commented out the full-sync -2 error return in the test daemon so that in the case of full syncs it will get all the members etc.
Current Tasks
For a run down of all the tasks and who is assigned to each task please refer to the detailed plan for lib_zdtm_sync.
Feature Requests
Interested in a new feature? Make a feature request.
Project History
First Phase
Originally ZSREP stood for Zaurus Synchronization Reverse Engineering Project. The project began with the reverse engineering the protocol used for synchronization between the Zaurus and the Desktop. The protocol has not been exhaustively reverse engineered, but we have explored enough of it to begin synchronization work.
Second Phase
The goal of the project turned to creating cross-platform synchronization software. To reflect the new goal the acronym changed to Zaurus Synchronization Repository. During this phase a command line tool, zync, was developed alongside the zync-gui frontend. This functional tool served to help explore the protocol.
Third Phase
The third and current phase of the project involves the fresh development of support libraries and an OpenSync plugin. OpenSync emerged out of gnome, kde, and other PIM groups. By implementing that standard our tool could be both platform and application independent.
Version Numbering
The version format that is used for releases in this project consists of three dot separated integer values. Each of the three integer values represents a revision (or rather, state) of the release. The left most integer is basically a counter used to identify which major release it is. A major release is an extremely stable and very feature complete release. Major releases will not occur very often. One may think of a major release as the version that would be released to the public as a product. The middle integer is a counter used to identify minor releases. A minor release is any release that contains new features or has had a reworking of the code (basically any substantial change in the code). Note: A minor number is associated with a major number so when the major is incremented the value of the minor number for that new major is initialized to zero. The third and right most number is the patch number. The patch number is basically a counter for patches that have been applied to a release. Note: A patch number is associated with a minor number so when the minor is incremented the value of the patch number for that new minor is initialized to zero.
For example, v1.2.3 would be a major release of 1, with a minor release of 2, and a patch release of 3. This would read as follows from left to right. This release v1.2.3 has had two minor releases since v1.0.0. Hence, it has had two pretty substantial changes made to it since v1.0.0. This release has also had three patches applied to it since version 1.2.0 producing the version 1.2.3.
