Hello Patrick, On Dec 8, 2010, at 12:26 , Patrick Ohly wrote:
> On Mi, 2010-12-08 at 12:22 +0100, Patrick Ohly wrote: >> I'm currently (involuntarily ;-) stress-testing this code by running >> SyncEvolution<->SyncEvolution syncs with lots of iCalendar 2.0 items, >> which happen to have very long IDs. > > Related to this: is there some way to increase the maximum ID size > advertised by the Synthesis engine? Does that make sense - tradeoff > between sending long IDs in messages and having to deal with the > mapping? > > It seems that currently the size is hard-coded, with different values > for binfile client and server. > > Server: > libsynthesis/src/sysync/localengineds.cpp: fMaxGUIDSize = 64; > > Client: > libsynthesis/src/sysync/binfileimplds.cpp: > fMaxGUIDSize=BINFILE_MAXGUIDSIZE; > libsynthesis/src/sysync/binfileimplds.h:#define BINFILE_MAXGUIDSIZE 63 In the client, it has to be hard coded because it is a field in the fixed binfile layout. If it is changed, the pendingmap will become incompatible (so PENDINGITEM_DB_VERSION should be incremented) and will be recreated with the new layout on next sync. This should do no harm except if the upgrade happens after a suspended or non-successful sync which actually has produced pending maps. In the server, fMaxGUIDSize is documentary only - clients don't need to check the server's maxGUIDsize (but clients with insanely long IDs will not work with servers that have a limit for the remoteID string size in the backend). Best Regards, Lukas PS: I'm still looking into the map example you provided and trying to understand it. I'll follow up as soon as I see through :-) _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
