On Wed, 2009-12-02 at 14:44 +0000, Lukas Zeller wrote: > 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.
So you are proposing to always use "text/x-vcalendar" (or its binary equivalent) even if we would prefer "text/calendar"? That might work, except for those hypothetical handsets which *only* support "text/calendar". > Apart from that - are there any real world handsets doing iCalendar? SyncEvolution via obexd? ;-) > > 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. Agreed. We'll have to solve the search path problems in SyncEvolution. So how do we proceed with this in the git repos? Do you think you can set up something which follows your existing fragments or should I split up the existing sample configs in our repo and you merge that back? > 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. The problem with that might be that the config has to be complete before the engine even knows what peer it is talking to. For other cases SyncEvolution already puts the desired settings into a generated XML config. -- 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
