Re: [os-libsynthesis] adding or overriding CtCap
On Mo, 2011-06-20 at 17:27 +0100, Patrick Ohly wrote:
> Problem solved...
Except for one field:
Profile:
This is getting set to AVAILABLE here:
if (proplistP) {
if (!itemTypeP->fReceivedFieldDefs) {
// there is a propList, and we haven't scanned one already for this type
// (could be the case for DS 1.2 vCalendar where we get events & tasks
separately)
// so disable all non-mandatory fields first (available ones will be
re-enabled)
for (sInt16 i=0; ifFieldDefinitionsP->numFields(); i++) {
itemTypeP->getFieldOptions(i)->available=false;
}
// force mandatory+unprocessed properties to be always "available"
=>setfieldoptions(NULL,fProfileDefinitionP,itemTypeP);
}
// now we have received fields
itemTypeP->fReceivedFieldDefs=true;
}
Verified with debugging output. I've not looked into setfieldoptions()
for the exact logic which enables the field.
This has the effect that my X-FOOBAR-EXTENSION and X-TEST extensions
(stored locally in XPROPS) are not getting preserved when importing the
updated contact from Google.
What would be a proper fix for this?
--
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
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] adding or overriding CtCap
On Mo, 2011-06-20 at 17:01 +0100, Patrick Ohly wrote: > I'm now looking at the actual parser code... gdb to the rescue. Medic! I shot myself into the foot. My overridden Google CtCap was taken from a dump of the CtCap generated by the Synthesis engine for my own profile. I still had the "X-messaging/aim-All" property listed there and of course, the AIM_HANDLE was faithfully set to AVAILABLE because of that. Problem solved... -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] adding or overriding CtCap
On Mo, 2011-06-20 at 15:03 +0100, Lukas Zeller wrote: > Hello, > > I don't see why it should work in the simple profile but not work in the > complex one. > > However, maybe this is a red herring and the problem lies in the > fReceivedFieldDefs (in TMimeDirItemType) flag. This is a per-type flag > which is set once a property list from devInf was parsed with > TMimeDirProfileHandler::analyzeCTCap(). That function is only called once during a sync session. The updated or added CtCap is inserted into TSyncSession::analyzeRemoteDevInf() by the checkRemoteSpecifics() call, which runs before the analyzeCTCap() call later in analyzeRemoteDevInf(). > Its effect is that when parsing a CTCap again (which is still > possible), the available status of the fields are NOT reset before > parsing the CTCap, such that possibly more fields get enabled, but > those that are already enabled from a previous CTCap scan remain > enabled. This is needed e.g. for combining vCalendar subtypes > VEVENT/VTODO. > > Could it be that the new OverrideDevInf somehow causes this flag to be > reset in an early stage, such that parsing the without X-AIM will > still result in AIM_HANDLE enabled, because it was set somehow > previously? So that doesn't seem to be it. I'm now looking at the actual parser code... gdb to the rescue. -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] compare scripts
On Fr, 2011-06-17 at 14:41 +0100, Lukas Zeller wrote:
> See the attached patch for a new script function COMPARISONMODE(), compiles
> but is UNTESTED.
I can confirm that it works. Thanks a lot. I'm going to add it as a
commit to the "master" branch on meego.gitorious.org.
> With this, your comparescript could probably look like:
>
>if (COMPARISONMODE!="age" &&
>TARGET.UID == REFERENCE.UID &&
>TARGET.ORIGSTART == REFERENCE.ORIGSTART) {
> RES = 0;
>} else {
>RES = COMPARE(TARGET.DMODIFIED, REFERENCE.DMODIFIED);
>}
Are you sure that the else clause for UID or RECURRENCE-ID not matching
should be another content comparison? If the comparison mode is not
"age", then I want to rely exclusively on UID/RECURRENCE-ID for
equal/not equal, and thus I have the following logic:
INTEGER RES;
if (COMPARISONMODE() != "age" && SESSIONVAR("VCALENDAR_COMPARE_UID") ) {
if (TARGET.UID == REFERENCE.UID &&
TARGET.ORIGSTART == REFERENCE.ORIGSTART) {
RES = 0;
} else {
RES = -999;
}
} else {
RES = COMPAREFIELDS();
}
The VCALENDAR_COMPARE_UID session variable will be false when I want the
default behavior. Does this look right?
--
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
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] adding or overriding CtCap
Hello, I don't see why it should work in the simple profile but not work in the complex one. However, maybe this is a red herring and the problem lies in the fReceivedFieldDefs (in TMimeDirItemType) flag. This is a per-type flag which is set once a property list from devInf was parsed with TMimeDirProfileHandler::analyzeCTCap(). Its effect is that when parsing a CTCap again (which is still possible), the available status of the fields are NOT reset before parsing the CTCap, such that possibly more fields get enabled, but those that are already enabled from a previous CTCap scan remain enabled. This is needed e.g. for combining vCalendar subtypes VEVENT/VTODO. Could it be that the new OverrideDevInf somehow causes this flag to be reset in an early stage, such that parsing the without X-AIM will still result in AIM_HANDLE enabled, because it was set somehow previously? Just an idea.. Lukas On Jun 20, 2011, at 14:05 , Patrick Ohly wrote: > [...] It almost works as intended, except for the chat information. > > They are defined as fields like this: > compare="conflict"/> > compare="conflict"/> > > And in the profile: > > > > rule="HAVE-EVOLUTION-UI-SLOT"> > > > > > > > > The logic in our profile is this: when talking to KDE in the Akonadi > backend, avoid using "X-AIM" and enable "X-messaging/aim-All" instead. > When talking to a SyncML peer or Evolution, use "X-AIM". > > Now when parsing a CtCap which does not mentioned > X-AIM at all, the engine > concludes that: > > - AIM_HANDLE : AVAILABLEmaxoccur=1, maxsize=0 (unlimited) > - AIM_SLOT : n/a maxoccur=0, maxsize=0 (unlimited) > > The "AIM_HANDLE = AVAILABLE" is wrong here. > > I also tried it with the simpler profile: > > > > > > > > Then it works. So apparently something in the rule parameter confuses > the CtCap parser. > > Any idea? > > -- > 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 > os-libsynthesis@synthesis.ch > http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] adding or overriding CtCap
On Mi, 2011-06-15 at 14:02 +0200, Patrick Ohly wrote: > Hello! > > One of the problems that we have in SyncEvolution is the loss of > properties not supported by SyncML servers, like Google: > https://bugs.meego.com/show_bug.cgi?id=15029 > > For example, BDAY is not supported and gets lost in a round-trip sync > because the client doesn't know that the server didn't store the field. > That's because the Google server does not provide CtCap as part of its > DevInf. > > The attached patches address this problem by allowing a RemoteRule to > provide CtCap information. > > It's not currently in the branch used by SyncEvolution, but I need to > add something like it soon. Comments welcome. > > I'm a bit undecided whether the RemoteRule should provide a DevInf or > only CtCap. Right now, only CtCap is used and the rest is ignored, but > perhaps that might change someday? Any comments about this patch and/or the approach? Thanks to Lukas' hint about the option I continued testing. It almost works as intended, except for the chat information. They are defined as fields like this: And in the profile: The logic in our profile is this: when talking to KDE in the Akonadi backend, avoid using "X-AIM" and enable "X-messaging/aim-All" instead. When talking to a SyncML peer or Evolution, use "X-AIM". Now when parsing a CtCap which does not mentioned X-AIM at all, the engine concludes that: - AIM_HANDLE : AVAILABLEmaxoccur=1, maxsize=0 (unlimited) - AIM_SLOT : n/a maxoccur=0, maxsize=0 (unlimited) The "AIM_HANDLE = AVAILABLE" is wrong here. I also tried it with the simpler profile: Then it works. So apparently something in the rule parameter confuses the CtCap parser. Any idea? -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
