[Kolab-devel] synckolab 0.4.13 - with kolab2 xml support (contact)
a.gungl at gmx.de
Tue May 10 09:10:58 CEST 2005
> I released 0.4.13 today. This version not only syncs correctly all
> deleted and changed cards/contacts, but this is the first one, that
> writes kolab2 xml format BACK to the imap account.
> Could some of you please test the extension (get it from
> http://www.gargan.org/extensions/synckolab.html ) if the kolab server
> can really read the contacts. Also if anyone would like to add the write
> back function for calendar you can find the code in the xpi+lots of
> utility functions+the xample from the address book.
> Looks like there is a new kolab2 client on its way :)
thanks for all the effort you've put into that extension so far. Even if
it looks like people don't care for it too much currently, I'm sure the
extension will get more attention once Kolab 2.0 final is released.
As far as testing goes, I'm using 0.4.13 on Win. I've configured only the
Calendar page to download my XML events and put them into the calendar.
Only the "Sync Calendar" checkbox is checked. When doing a sync I run into
error: this.gAddressBook has no properties
If I comment the line, the sync of the events succeeds. (Of course, it's
only a workaround.)
BTW, directly after starting the sync I get an error messagebox telling
"unable to read ...Calendar/CalendarDat" <- line is cut of here, the rest
of the file name is invisible, it might be CalendarDataFile.ics, which
exists and is not read-only or so
"... location: JSFrame :: chrome://calendar/content/importExport.js ::
convertToUnicode :: line 98"
Hitting OK lets the sync process continue. This seems to be a Sunbird
problem though. I just wonder about how that error effects the data in the
A general thought about the implementation:
In calendar.js, there are quite a lot of variable names which refer to
address specific things. I guess this is due to copying addressbook.js
somewhen in the development process. Unfortunatly this makes the whole
code very hard to read. For example see "parseMessage:
function(fileContent)". There you seem to deal with cards (VCards ?)
having a weak type concept compared to e.g. C++, you can't simply look at
the type to get an idea of the code. You have to try it, to debug it to
see what really happens.
It would be great to have that fixed, so that other people can contribute
Best regards and thanks again for working on SyncKolab
+++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail
More information about the Kolab-devel