Hello Mika, Nice to hear that you are working on it. As you have noticed, the syncml engine code is somewhat hard to follow. One of the main problems is that the SyncML standard suffers from the good ol' problem of being command-response-based, and it does not state how a server or client should react when the other end issues an unexpected sequence of commands. Anyway...
> - you have to support the SyncHdr/RespURI element, since this is > used for transforming the login into a session-id including > application-URL. I did implement this a couple of weeks ago, but I see now that I forgot to check it in. It should be in CVS now (or, as usual, soon). > Calmeno sends something like > <RespURI>http://www.weblicon.net, demo.calmeno.net/...</RespURI> which > seems to mean that we should connect to www.weblicon.net but use > demo.calmeno.net in the HTTP Host: header (but connecting to > demo.calmeno.net works as well). I'm not quite convinced this is a valid > URI (URL), but we should be able to parse it. That seems like a very strange URI. In the standard says that the RespURI data should be just an absolute URI. Try the CVS code now and see if it works good enough. > - if we get a 407 (missing auth) back we must resend the auth This is supposed to be done. Could you send me an example where this does not work? > - evolution and calmeno support timezones. Evolution defines its > timezones in the beginning of the VCALENDAR and refers to them in the > VEVENTS -> the actual correct timezone isn't transmitted, since the > VCALENDAR header info is lost on the way somewhere. ... I'm not sure I understood it all, but you could try adding VOPTION_CONVERTUTC to the sync_vtype_convert() calls in syncml_engine.c. This will convert any UTC times to local time. > Actually weird was that the source said in > syncml_convert_copy_change_list: > > if (type == SYNCML_DATA_TYPE_VCALENDAR1 && obj->change.comp) { > // We have to convert to vCALENDAR 1.0 > vopts |= VOPTION_CALENDAR2TO1; > } > > which doesn't make sense. I changed the SYNCML_DATA_TYPE_VCALENDAR1 to > SYNCML_DATA_TYPE_VCALENDAR2. Hmm, I still think it's right. The idea with this function is to take MultiSync data (which should be vCAL version 2.0) and convert it to vCAL1.0 if the other SyncML end states that it does not understand 2.0. > - calmeno doesn't set the UID in the VEVENT, it sets Item/Source/LocURI > instead. When the VEVENT is pushed to evolution it generates the UID so > changes/deletes don't work from evo to calmeno. I think this is allowed > by the spec. Definately. Let me see if I got you right: You have an Evo<->SyncML client pair in MultiSync and connect to calmeno. The entries that are changed in calmeno does not change the corresponding ones in Evo, but instead new entries are created every time? > - It seems that deletes don't work in any case. I'm looking into this. OK. > - The server disconnects after a '<Final />' element, so we should > re-establish the connection. This doesn't work, multisync gets stuck > instead (at least in some cases), so synchronization works once after > startup (I think). The protocol handling doesn't look too robust in any > case. You're definately right about that :-) > - alarms don't go to calmeno neither as vcal 1 or vcal 2. Don't know if > this is a problem with the data or with OK. > I don't know what's the best way to work on this. Comments, Bo? Well, I'd definately be happy if you would want to take the time to read the specs and the syncml_engine code and see what needs to be done. As you may have noticed, a lot of my time is consumed by the other plugins as well. Of course I will help you as much as I can. Best / Bo ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Multisync-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/multisync-devel
