Hi Patrick, On Jul 11, 2011, at 8:29 , Patrick Ohly wrote:
>>> The key question is: is the assumption that a peer supports extensions >>> or is the assumption that it doesn't? >> >> So far, the assumption was that it does. > > After some testing, my experience is the opposite. My interpretation of "support" in the above was not "does actually store", but "does not crash when a X-* property occurs". Of course I agree with you that most implementation cannot generally store X-* properies - at most a few specific ones. > After adding some new > X- chat extensions, all of the peers started to fail the "item copy" > test because they didn't support these extensions. After reporting that, > Memotoo added support. >> [...] I'd say most clients can at least >> handle unknown properties without crashing. > > Yes, but they don't store them. Agreed >> [...] >>> Does it have to be marked as "available" to be used when parsing? >> >> Yes. I thought a lot about this, but IMHO it doesn't make sense to >> accept data that won't be sent back later. Because when it is parsed >> and appears in a client device, a user might change it and will >> certainly be confused when it does not sync back to the originator. So >> it's either parse and generate, or neither. > > With MAKE/PARSETEXTWITHPROFILE() the X-* property is parsed and > generated. Probably because they don't really use CtCap information to > determine which properties are available. Only the rules are checked. The "available" status for a field is a AND between the "available" flag in the field options of the TMultiFieldItemType associated with the local datastore (the one generated from config, which usually has "available" set for all fields) and the one associated with the remote datastore (the one that gets the "available" flags set from CTCap) - see TMultiFieldItem::isAvailable() function. I'm non entirely sure if the MAKE/PARSETEXTWITHPROFILE() is entirely clean in that respect - it depends on where the item processed comes from (i.e. its fItemTypeP and fTargetItemTypeP). This was designed with the idea that every conversion always has a SyncML end (i.e. is either generated or parsed by the remote), but this is not exactly the case for MAKE/PARSETEXTWITHPROFILE() used towards the DB backend, so this might need some tweaking of TMultiFieldItem::isAvailable() depending how MAKE/PARSETEXTWITHPROFILE() is used. Best Regards, Lukas Lukas Zeller, plan44.ch [email protected] - www.plan44.ch _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
