Thanks for your reply. > Hi. thanks for your patches! > > On Sat, 2004-09-11 at 18:44, YuLei wrote: > > After some weeks hacking, multisync is now usable for me. > > I am using T68, Evolution and Palm on Debian Sarge with chinese GBK > > environment, and I hope multisync will be my final solution for sync PIM > > data with different devices. > > > > Here are my patches: > > 02-palm_category.patch > > -- see > > http://sourceforge.net/mailarchive/forum.php?thread_id=5437490&forum_id=12899 > > > > ok to commit. > > > 03-utf8.patch > > -- see > > http://sourceforge.net/mailarchive/forum.php?thread_id=5092577&forum_id=31160 > > > > this patch converts a vcards encoding to UTF-8 if it is something > different, correct? yes.
> Why are you working on the vcards directly? Wouldnt it be much better to > use the libversit? records from my T68 is UTF-7 encoding, and some value has the property 'CHARSET=UTF7', but in function 'sync_vtype_convert', this property has not been used, and the output value of vcard also lost this property, so Evolution will get the wrong value because no charset specified Sorry, I know nothing about libversit :( , maybe that is the better way > BTW: the g_strescape madness in my palm plugin was already fixed in CVS > :) yes, this is not included in my patch :) > > > > 04-evo_utf8_char_edge.patch > > -- line of records got from evoluion will be wrapped if too long, but > > evolution does care nothing about the edge of characters which has > > multi-bytes encoding, such as UTF8, if wrap occured in the middle of one > > such character, multisync will crash because invalid UTF8 character, so > > I add this patch to join all wrapped lines before do any processing. > > And i dont really understand what you mean with "if wrap occured in the > middle of one such character" because UTF8 is multi-byte encoding, this means an atom character of one language (such as chinese) may has 2 or 3 bytes, if you wrap a line at the fixed width, you cannot guarantee the wrap point is not inside in an such character, maybe will break a multi-byte character into two lines, multisync can not handle this, and will crash, so the easy way to prevent this is to first join all the wrapped lines > > btw: strcpy(p, p+2) ? > > man strcpy > <snip> > The strings may not overlap, and the destination string dest must be > large enough to receive the copy. > <snap> this code is to remove the trail '\n' and the first space character of next line, I don't know the problem of this code ? > > > > > 05-evo_lost_records.patch > > -- see > > http://sourceforge.net/mailarchive/forum.php?thread_id=5319816&forum_id=31160 > > > > cant comment on this one. i dont know enough about the inner workings of > the evo plugin this problem is exist, I cost many time to debug, if the record number is large (> 400), after sync, you can see the debug message "We found xx unexpected changes" > > > 06-evo_work_fax_entry.patch > > -- sync T68 to Evolution, phone with label 'Work' on T68 will save to > > 'Work' entry on Evolution, that's ok, but this entry will never sync to > > Palm, instead, multisync sync 'Business' entry on Evolution to Palm as > > 'Work', this patch convert all 'Work' entry from T68 to 'Business' and > > 'Fax' to 'Business Fax'. > > why are you fixing this on the evo side? you say that "TEL;WORK" will > appear in evo as "Work", correct? yes T68 Evolution Palm ------------------------ Work -- Work Business -- Work | | +----- break ------+ > > If this isnt synced to "work" on the palm properly it should be fixed on > the palm plugin. I think this is only a quick fix, or fix this at IrMC plugin is better > > > > > 07-irmc_cant_remove_rec.patch > > -- a deleted record on T68 will not be deleted after synchronize and > > just become an empty record on Evolution > > looks good from here. but maybe change ret < 0 to ret != 0. Dont know if > there are positive error codes. Comments anyone? maybe yes, I don't know > > > > > 08-multi_filter.patch > > -- filter now support multiple items with comma separated, such as > > category list > > looks good. great idea btw :) thanks :) , I have too many address records, and can not put all of them to my T68, so I use filter to sync some of them to T68 based on category > > > > > 09-evo_preserve_categories.patch > > -- if some records was modified on T68, after sync with Evolution, all > > categories info on Evolution will be lost > > -- same problem with 'Note' entry on Evolution and Palm, because there > > is no such entry on T68, so, if a record was modified on T68 and then > > sync back, this entry will be lost. I will try to fix this if I have > > time. > > could you please elaborate a bit more on this problem (the first part). > So a contact with categories is synced to the T68, then modified. If it > is synced again the category information in evo will be lost, correct? > does the t68 support categories? this patch is a bit complex, for my poor English, maybe my code is the better way to explain, sorry :( T68 does not support categories, but it has a fixed category named 'APPOINT' for tasks and events, and no category for address book > > To the second part: This cannot be fixed in this version of multisync. > The current syncengine is no "smart" engine that is able to merge the > information of vcards. So if a device cannot support certain atributes > of the vcard, is modified and then synced back, then unsupported > information will be lost. There is no way to prevent this. Every attempt > will probably be a crude hack that will work for you but might break > things for others. > > The next version of multisync will hopefully be able to deal with this. I think the syncengine should has its own database to save all the data of individual devices separately, and can merge the changes of two devices when sync between them > > > > > 10-evo_default_category.patch > > -- add default category 'Unfiled' to any changed records if no category > > was specified, because I have no idea to find out the records which has > > no category on Evolution's addressbook > > why are you adding this Category? And why exactly "unfiled"? > because the records of address book on T68 has no categories, and Evolution has bug of searching records which has no categories, so if I add a new address record on T68 and then sync to Evolution, it is hard to find out ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php _______________________________________________ Multisync-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/multisync-users
