Hi all. I am the founder and lead developer of Zync and Zync-GUI. The only true sync solution for DTM based Zaurus ROMs. I have been working my but off trying to get this thing totally implemented and into a solid beta stage. However, I have heard from very few of you in testing it. This is some what sad, I would have thought that such an effort to provide a good solution for synchronization would mean a lot to the Linux/Zaurus community.

Anyways, due to life in general and the fact that I do not get payed to develop this software, I am going to need some help to get it done sooner so that we all have full sync capabilites with our Zauri.

I have made it very easy for people to develop plugins for zync to work with different Personal Information Management suites on the desktop. The plugin specs are very rigid and defined so there is no guessing like with other plugin architectures out there. I have no problem implementing the non plugin portions which have yet to be implemented. But, it would happen a lot quicker if some other members of the community could work from the opposite direction and implemented plugins for their choice of desktop PIM applications.

I have already implemented the KOrganizer ToDo plugin for zync. If you are interested in writing a plugin for zync please please please e-mail me at cyphactor@socal.rr.com or respond to this post.

Information on Zync, Zync-GUI, and an abundance of information can be found at http://zsrep.sourceforge.net. Please please please, help I want to get this done!!

Thanks,
Andrew De Ponte

I would be interested in seeing zync working under OS X and Windows(cygwin), as I don't use a linux box on a regular basis.

I (briefly) attempted to compile zync under both of these platforms. On OS X, the libraries will not build properly as the method for building libraries under OS X is a bit different. Under cygwin, a few functions are not available (inet_ntop/pton, may be able to use inet_ntoa/aton instead), and the libraries could not be seen after building (reason unknown).

Korganizer can run on both platforms, so the current plugin could be used for testing zync once it is built.

- ashikase
- anpachi, gifu, japan

Yes, I would love to get zync working for OS X. I don't have an OS X box though. I am looking into buying an OS X box, at which point I will port it to OS X. It really shouldn't be that much of a problem to port to OS X. As to the cygwin issues. I could port it to cygwin as well. I am not sure how the library database works in cygwin, you would have to look into that. There has to be an equivalent of ldconfig and /etc/ld.so.conf which should contain /usr/local/lib in it.

You are correct about the inet_ntop/pton being able to be replaced by inet_ntoa/aton. The latter are deprecated functions, hence, the proper thing to do would be for cygwin to support the inet_ntop/pton functions. But, until that is done, it would be just a tad of work to get it working under cygwin it seems.

Despite this my priority is to get a full set of plugins for it so that not only the Todo list can be synced, but also the Calendar and Address Book.

I would love it if you would take the current release of zync and try to get it compiled on cygwin by replacing the inet_ntop/pton functions with inet_ntoa/aton functions. Please let me know if you do. I am a strict unix/linux user hence I have no windows box running cygwin so it is difficult for me to test.

I am very very very interested in getting zync working with Mac OS X. It is definitely a needed tool on the Mac OS X side as well as the linux side.

Please let me know what you are going to do if anything.

Thanks,
Andrew De Ponte

I'd be willing to donate a Mac with OS X on it to your efforts, I have a Blue & White G3 that I'm not presently using, Are you in the US?

It's not the fastest or newest machine but it should help.

That would be great! Yes, I am in the US, more specifically Los Angeles/Orange County area of California. How, would you like to work the shipping out?

Well, I've just bought a C860, new user here, and I'm willing to give feedback to help improve anything you develop, but I've got a suggestion for you. I don't know if it's been discussed before, but I'll throw my two cents anyway.

Being a kde cvs user myself, I believe kdepim developers aren't yet into the syncing business, as their main efforts are headed to groupware solutions (god bless Kolab Imap resource).

But in the meantime, while they realize about the fact that PIM should sync with anything, a new project is being developed right now, which could help to solve this situation.

I'm talking about OpenSync. Even though it's about to reach beta stages it already includes support for kdepim and evolution among others.

Why don't you develop a DTM plugin for OpenSync?

You wouldn't have to choose between evolution or kde, just program a plugin based in the opensync framework.

Finally they got rid of multisync gnomish dependencies, it's just a plain c project, without unneeded software layers.

And sooner or later kdepim people will realize that opensync project is a good thing.

Opinions?


(After writing this stuff, I've noticed you wrote an email to the opensync ml, that's great... )

Recently there was a kdepim hackers meeting in osnabrueck, this is what they had to say about syncing

Well, I have thought about developing a DTM plugin for OpenSync because OpenSync does seem like the right thing to due over all. However, after checking out the latest version from their subversion server I ran ./configure and found the following:

configure: WARNING: Couldn't find either Pyrex or the Python headers, not building Python bindings
checking for glib-2.0 gmodule-2.0 gobject-2.0 gthread-2.0 sqlite3... Package sqlite3 was not found in the pkg-config search path.
Perhaps you should add the directory containing `sqlite3.pc'
to the PKG_CONFIG_PATH environment variable
No package 'sqlite3' found

configure: error: Library requirements (glib-2.0 gmodule-2.0 gobject-2.0 gthread-2.0 sqlite3) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.

As you can see glib-2.0, gmodule-2.0, gobject-2.0, gthread-2.0, sqlite3, Pyrex, Python, and pkg_config are all required. Those seem to be just a few of the requirements. Having this many dependencies for doing what it does is not acceptable in my opinion. Granted it is a possibility that some of these dependencies may be for plugins. If that is the case then the plugins should be extracted from the main opensync project and should exist as individual packages. Beyond that each plugin should only have the dependencies required to interact with their associated desktop PIM application.

I am sorry, but all of these items which I have listed in the above paragraph in my experience produce difficult to use, bloated, packages which is not an acceptable path to take when developing a project for a user based community rather than a developer based community. This is just my opinion, and because of it I have decided that I will not write a DTM plugin for opensync at this point.

My goal is to produce the best product, note I say product, that I possibly can. I am going at the development of this project as I would if I was developing a solution for this problem as a product which would be sold in stores. It seems that most open source projects these days go at the development in a manner more oriented torwards research rather than torwards product production.

Well, that is my opinion and reasoning behind it.

Any questions, suggestions, opinions?

Just an update... with a little bit of tweaking, I was able to get zync to compile under both Windows/cygwin and OS X. However, I have no way of testing it; the build of KDE for cygwin appears to not include korganizer, and as for OS X, I cannot get the korganizer plugin to build.

I wonder how hard it would be to write a thunderbird plugin... maybe if I get some time some day...

EDIT: is there any way to test if zync is working, even without the todo plugin?

- ashikase
- anpachi, gifu, japan

That is great, I would appreciate it if you would send me the modified version of the source for zync for both cygwin, and OS X to cyphactor@socal.rr.com. That sucks that cygwin does not include korganizer.

So, are you saying that korganizer exists and is installed on your OS X box but you can't get the korganizer plugin to build? If this is the case please join the developers mailing list and post the build output there. I am very interested in why the build did not work. It may be just because libraries and headers are installed in different places on OS X or something like that.



I am not sure how hard it would be to write a plugin for thunderbird. It all depends on the API which exists for interfacing with thunderbird and its associated PIM database.



Well, the easiest thing I can think of for testing it with out hacking with the code too much is to write a simple stub To-Do plug-in for zync. What I mean by that is to write a plug-in which say instead of actually adding the new items to the desktop just prints the new items info to the screen. The plug-in would also not actually delete the items which have been deleted it would just output that it would normally do so, and so on and so forth for the required functions.

Note: The reason I suggest To-Do plug-in is because it has few fields to print out. I may be able to help you with production of such a plug-in if you want to test it this way. The Zaurus portion of Zync sholud work under OS X with no problem as long as your OS X box has TCP/IP networking setup between your Zaurus and OS X box via the cradle.

Sorry for taking so long to reply; I had to wait a couple of days for a compile of the latest KDE for OS X to finish after having realized that the version I already had installed was a bit old.

So far, I've gotten both zync and the korg plugin to work under OS X... up to a certain point.

Getting zync to compile on OS X is pretty easy. In the makefiles for the 3 libraries, change the *_OUT_FILENAME extension from ".so" to ".dylib" (ex. "libzmsg.dylib"), and change the SONAME_FLAG to "-dynamic_lib -install_name " (note the final space, it is necessary). That's it.

The 'install' target doesn't work from the archive's root directory; I had to run 'make install' from within the "src" directory. Also, /usr/local/lib didn't exist on my machine, so I had to create the directory and add it to my LIBRARY_PATH (added an export to my .bash_profile).

As for the korg todo plugin, I set the *_OUT_FILENAME extension to ".dylib" (the extension in this case probably doesn't matter, as the filename can be set in the zync configuration file; in fact, bundles in OS X probably use a different extension altogether), set SONAME_FLAG to "-bundle", and removed the "$(*_OUT_FILENAME).0" from the target (-install_name can only be used with -dynamiclib; OS X differentiates between dynamically loaded libraries and bundles/plugins). I also found that I had to add a direct link to my qt library ("/sw/lib/libqt-mt.3.dylib") to the list of libraries, as the compiler complained of an illegal indirect reference to it.

Again, the install target had to be run from within the "src" directory.

When I first tried using the program, I found that the sync would start on the Zaurus and then immediately claim that it was interrupted. It turned out to be a problem with byte ordering of the body size and checksum. While your "GetHostByteOrder" function correctly detects that OS X is big-endian, the ntohs function does *not* swap the bytes. According to the ntohs man pages, at least under OS X, the ntohs function (and similar functions) are defined as null macros for big-endian systems, as both the host and network ordering scheme is big-endian. I got around this by manually swapping the bytes (making use of your union type from the GetHostByteOrder function).

So far I can run 'zync -t', and it will connect with the zaurus and start processing. However, at one point it complains that the number of bytes is less than 20, and that the message received (7 bytes) was an Abort message. Below is an excerpt of the output:



At this point, it just hangs. I would research further, but it's late. Any ideas on what might be wrong or where to look?

Sorry for such a long explanation; I hope you were able to follow it.

As a side note... the above was tested with a fresh C760 Sharp ROM; for some reason, it seems that sync is not working on Cacko Lite 1.22a (I don't know about other Cacko ROMS). It doesn't even work with Sharp's default Zaurus sync software for Windows. Do you (or anyone out there) know anything about this?

- ashikase
- anpachi, gifu, japan

Interesting, I am not sure that you want the bundles/plugins build, it should really be a dynamic library. Zync at least treats it as if it is a dynamic linked library.



Yeah, I have not fully implemented the conversion in some places, so it may assume that things are in little endian. Very, interesting, I didn't know that they were implemented as NULL macros. As soon as I get a Mac OS X system I will solve all these byte order problems.



Interesting. First off the num New Sync IDs: 512 is claiming that it found that you had 512 items in your To-Do list on your Zaurus. I am assuming that this is wrong. Second, if you have never synced your Zaurus before it should be doing a Full Sync, meaning that Mod Sync IDs and Del Sync IDs should both be 0.

Hmmm, it is really hard to tell exactly what happened without a packet capture of the traffic that went over the USB network device. You can obtain such a packet capture by using tcpdump or ethereal while attempting to perform a sync. I will be able to give you a much better idea of what is going on as soon as I see the packet capture.

I really, wish I had a Mac OS X box, then I could test this myself and see what was going on. Anyways, post the packet capture as soon as possible and we will figure out what is going on.



Well, you do have to make sure you have the latest version of the Windows software released by Sharp. There are two different DTM supporting versions. I got it off the http://www.myzaurus.com site in their downloads section, you should also be able to get it off of the http://www.zaurususergroup.org site.

The Windows software version isn't the problem. When using the original Sharp ROM, syncing under Windows (with Sharp's software) works; when using Cacko, it doesn't. In both cases, it's DTM.

- ashikase
- anpachi, gifu, japan

Ah, I see. Well, do you know what Sharp ROM the Cacko ROM is based on. Is it the older DTM rom? If that is not the problem I am not sure. I have not played around with the Cacko ROMs too much. But, having a packet capture of what the Cacko ROM is trying to do might spread some light on it.

I'd like to put in my vote for syncing to OS X using zync. I don't have any programming abilities to speak of, but I can put myself to work as a guinea pig if you need help. I'm running the latest version of OS X and using an SL-6000, a configuration a lot of users seem to have but developers don't.

What I'd really like to see is syncing to/from the DTM using the standard Apple apps: iCal (uses .ical format, just like KO/Pi) and Address Book (.vcf, though KA/Pi is struggling with v3.0). Even better would be integration with iSync. Tiger (OS X 10.4), as I understand it, is opening up the iSync API so developers can integrate it with their apps system-wide, and developer copies of Tiger are available all over BT sites. I already have two major PIM suites on my iBook, Apple's and Microsoft's, and adding KOrganizer to that would seem to be overkill.

cyphactor,

Firstly, thank you for what you are doing, I'm sure that there are a lot of people here who will appreciate some way to sync with Linux apps such as kdepim, evolution etc...

I just can't help thinking that OpenSync would be a much easier solution, which would provide quicker results, and would be much easier to maintain in the future.

It seems to me, that OpenSync would allow you (and anyone else that helps) to concentrate on the Zaurus side of things and getting that right. No need to worry about all the different PIM software out there as other developers will be able to take care of that. Also the infrastructure etc will all be done for you. And when Evolution changes something, well you should just be able to pick up the new Evolution plugin for OpenSync and off you go. If you continue with this project as-is then you'll constantly have to maintain plugins for all the different PIM software.

The pool of developers working on OpenSync is bound to be greater than those working on Zync, purely because OpenSync will have a much broader user base and hence interest will be naturally higher, does it not make sense to tap into this?

I do understand your issues with all the dependancies... I think this is one of the biggest problems for a lot of users with Linux... they try to install an app, find it needs x number of dependancies, each of which require x more etc etc... I've been there, and yes it's a pain... it's getting slightly easier with things like APT, but still. I still think that painful as this is though, it's still got to be easier than implementing, effectively, a duplicate of OpenSync...

Just my 2 cents... and caveat here - I don't even have a Zaurus yet!

Good luck with whatever you decide, and when I get my Z I may even be tempted to help...

Matt

If I had a Mac (I am working on aquiering one right now) I would be working on integration with Mac. I have been talking to a couple of people who have taken the code and compiled it on Mac and am going to start working on debugging it and making sure it is portable to Linux and Mac. I will need all the Mac testers I can get.

Well, thank you very much for your acknowledgment of all my hard work and efforts in this project.



Yes, OpenSync did, from the initial perspective, look like a much easier solution. Such, that would provide quicker results and would be much easier to maintain in the future. However, after looking at the OpenSync code and the way it is setup I decided that it would take me longer and be more painful to implement the Zaurus sync into OpenSync. You are totally correct about the problem with maintaining plugins for all the different desktop PIM applications. This could stand to be a huge problem depending on how much the APIs for integrating with the PIM applications change. Hopefully they won't change very much and it won't be two hard to maintain them.

I also have designed the plugin interface for Zync so that it is very very easy to write plugins.



I am still going to stick with going the direction I am. Beyond the dependency problems, ugly design / lack of code docs / etc, in my opinion (no offense to designers, I just think it could have been done better. I do understand it is in early dev stages but still.), there is also the problem of making it portable. It will be a lot easier for me to tackle my infrastructure and plugin API in making them portable than it would be to do it with OpenSync (that is without adding even more dependencies).

I already have pretty much everything implemented except for all the plugins. The To-Do plugin should be very stable I have been using Zync and the KOrganizer To-Do plugin for a while and have had no problems. I am working on changing some internals in the Zaurus sync protocol implementation to make it better designed and better implemented along with making it more robust so that if a new version of the DTM sync protocol comes out zync will be able to handle it without any code changes.

Let me know when you get your Zaurus, I can use any help in testing or development that you can give.