Hi Patrick, On Dec 2, 2009, at 13:21 , Patrick Ohly wrote:
>> 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. I doubt (but haven't tried to prove) that the MIME type in the SAN would really influence type negotiation, I'd assume it is used as a safer identifier for the store than the name is, but as long as you use a mime type that is valid for that datastore I'd expect it would trigger a sync in the same way as a manual start would. Apart from that - are there any real world handsets doing iCalendar? > 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). Yes, makes much sense. In fact, we are generating our own sample configs from a bunch of such fragments (PHP files) for years already. We have once thought about allowing includes through XML processing instructions in the config itself, but discarded the idea as it would introduce a heap of sideline problems like search paths, and probably that alone would not be sufficient to solve the real world modularisation required. IMHO using some sort of external config preprocessing (be it PHP or M4 or whatever running at build time, or ad-hoc generation at runtime) is the better approach for anything beyond what can be done with the engine's config variables and the built-in "if/ifdef/ifndef" attribute system. 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
