On Wed, 2009-12-02 at 10:07 +0000, Lukas Zeller wrote: > On Dec 2, 2009, at 8:50 , Chen Congwu wrote: > > 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).
The problem in this case is that in order to start the automatic type negotiation, the right type must already be known when generating the SAN message. Apparently the Nokia phone uses the MIME type in the SAN instead of the datastore name to determine whether it supports it. This looks like something that we need to handle in SyncEvolution's "database" of know devices or known device families. > > 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. Did you see my proposal to change the distribution of the example configs? Instead of including two monolithic examples which partly overlap (profiles), I'd prefer to have several smaller files with atomic units (one rule/profile/field list/etc per file). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
