Hi Congwu, On Dec 2, 2009, at 8:50 , Chen Congwu wrote:
> Hi, I am encountering several questions syncing calendar with Nokia 7210c, > please be patient,;-) :-) > 1. Shall I use legacy mode? Since 7210c only supports vcalendar 1.0 (It does > not accept ical content type via SAN and it sends messages in vcal1.0 > format, so I assume this.) I just skimmed the sample configuraiton in > syncserver_sample.xml and found some remote rule configuraitons for various > phones, but did not see explict use of legacy mode. Have I made something > wrong? The approach with our server is as follows: as little device specific behaviour as possible. So unless we found that a device does not work, there is no remoterule. With the large majority of devices, legacy mode is not needed. Unlike servers, which often have very poor devInf (because very few clients actually check it at all), most clients have proper devInf. So automatic type negotiation should work (I'm not aware of a single device which did not work). > 2. Shall we (SyncEvolution) merge the remote rule configurations for > various phones already done by synthesis, so that we can benefit > immediately from synthesis excellent work. I'd recommend so. However, the rules that we have are mainly for ancient handsets. Most devices released in the past 3-4 years didn't need special rules any more. So that part of the config has become pretty static. However, please note fe11bb62b5 (server config: updated for 3.4.0.0 engine, fixed some bugs) I just posted - because of a change in the engine's default behaviour when interpreting text with no character set specified (in vCard 2.1/vCalendar 1.0 that is), some of these ancient remote rules need an update. > And of course we will > contribute back our new findings. So we need to setup a similar syncing > approach for configuration files for server case just like what we are > doing for client configurations? Probably yes. The remote rule part is largely independent of the rest of the config, so that should be easy to update with new entries on both sides. > To Patrick, do we need to seperate the server and client configurations just > like synthesis or stick to the combined approach we used at the moment? > > 3. TZ property is only declared in VCalendar profile, while the particular > phone sends it within vEvent subprofile, so I added the following to our > configuration: > <subprofile name="VEVENT" nummandatory="1" showifselectedonly="yes" > field="ISEVENT" value="1"> > > + <property onlyformode="old" name="TZ" filter="false" > suppressempty="yes"> > + <value field="DTSTART" conversion="tz"/> > + </property> > > Yes, it is non-standard compliant. So can I have a specific profile for this > particular phone? You can add a "rule" attribute to a property to enable it only when a certain remote rule is active. > 4. STATUS property maybe used directly instead of as a parameter for ATTANDEE > property inside vEvent profile (This is vcal1.0 explictly states). So I will > add this declarion in vEvent subprofile. At this moment it parsed correctly, > however when it starts to store to datastore (during beforewrotescript), it > still losts the STATUS, I am checking on this at the moment. > > 5. For clients which do not support UTC time (common case for phones?), Common for very old ones, and forced via remote rules for phones known having broken UTC/localtime conversion. Phones released in the last 3-4 years usually have working UTC conversion. Some may lack the <utc/> flag in the devInf, these can be fixed by a remote rule forcing the engine to use UTC even if the flag is missing. > [...] we will > send the time as localtime (not floating time? Does it mean vcal1.0 does not > have such a concept?). vCal 1.0 cannot really differentiate local and floating time. Of course, when there is a TZ/DAYLIGHT, the timestamps are not floating, but in that time zone. However a missing TZ/DAYLIGHT in many cases also means "local time". This is all a bit fuzzy with vCalendar 1.0. > However we did not sent the TZ field to client, how can > the client correctly interprect this? It can't, but clients not capable of UTC usually can't do anything more than just display the time as-is. So sending it in "usertimezone" is the best match we can get. (see config reference doc about "usertimezone", by default this is the server's local tz, but can vary on a per-user level, e.g. by loading a user preference in one of the <loginXXXXscript>). > see example: > This is what local datastore is: > BEGIN:VCALENDAR > CALSCALE:GREGORIAN > PRODID:-//Ximian//NONSGML Evolution Calendar//EN > VERSION:2.0 > BEGIN:VEVENT > SUMMARY:phone meeting > DTEND:20060406T163000Z > DTSTART:20060406T160000Z > DTSTAMP:20060406T211449Z > LOCATION:my office > DESCRIPTION:let's talk<<REVISION>> > UID:20091202t070241z-12684-1000-...@shlabwcchen35 > CREATED:20091202T070241Z > LAST-MODIFIED:20091202T070241Z > END:VEVENT > END:VCALENDAR > > This is what we sent: > BEGIN:VCALENDAR > VERSION:1.0 > BEGIN:VEVENT > SUMMARY:phone meeting > DESCRIPTION:let's talk<<REVISION>> > LOCATION:my office > DTSTART:20060407T000000 > DTEND:20060407T003000 > END:VEVENT > END:VCALENDAR > -- Best Regards, Lukas Zeller ([email protected]) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts [email protected], http://www.synthesis.ch _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
