Development Information

SVN Logs

r111 -- cyphactor -- 2007-07-30 00:49:05 -0700 -- 13 lines

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

r110 -- cyphactor -- 2007-05-07 17:15:40 -0700 -- 38 lines

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

r109 -- cyphactor -- 2007-05-02 17:47:20 -0700 -- 5 lines

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

r108 -- cyphactor -- 2007-04-05 00:09:49 -0700 -- 25 lines

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

r107 -- cyphactor -- 2007-04-04 18:35:19 -0700 -- 20 lines

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

r106 -- cyphactor -- 2007-04-04 17:23:10 -0700 -- 12 lines

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

r105 -- cyphactor -- 2007-04-04 13:39:17 -0700 -- 4 lines

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

r104 -- cyphactor -- 2007-03-28 20:28:27 -0700 -- 3 lines

* Modified the lib_zdtm_sync_detailed_plan.planner file to reflect Rob's 
work today.

r103 -- cyphactor -- 2007-03-28 20:17:54 -0700 -- 6 lines

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