Hi Patrick, On Dec 2, 2009, at 16:08 , Patrick Ohly wrote:
>> 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". Yes :-) >> Apart from that - are there any real world handsets doing iCalendar? > > SyncEvolution via obexd? ;-) Yes, and the iPhone (but that without SAN). But these will negotiate the type via devInf, no matter how they were alerted. >>> 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? The current libsynthesis samples are not generated from fragments, but manually derived from the iPhone configs at this time. So I'd prefer to merge back your proposal and possibly re-use that later for the iPhone and other libsynthesis based products. Feel free to structure it according to your needs. >> 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. Maybe for the per-peer dependency cases we'd need to enhance the remoterules system. The entire design of the config is that once a server starts operating, the config remains constant (strictly read-only object tree, possibly shared between multiple sessions in multiple threads). This was for efficiency and footprint (back in 2001) to avoid re-reading and re-resolving all config and scripts for every sync. 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
