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: > <field name="AIM_HANDLE" array="yes" type="string" > compare="conflict"/> > <field name="AIM_SLOT" array="yes" type="string" > compare="conflict"/> > > And in the profile: > <property name="X-AIM" suppressempty="yes" rule="KDE"/> > <property name="X-AIM" suppressempty="yes" rule="other"> > <value field="AIM_HANDLE"/> > <parameter name="X-EVOLUTION-UI-SLOT" positional="no" show="no" > rule="HAVE-EVOLUTION-UI-SLOT"> > <value field="AIM_SLOT"/> > </parameter> > </property> > <property name="X-messaging/aim-All" suppressempty="yes" rule="KDE"> > <value field="AIM_HANDLE"/> > </property> > > 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 > <Property><PropName>X-AIM</PropName></Property> at all, the engine > concludes that: > > - AIM_HANDLE : AVAILABLE maxoccur=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: > <property name="X-AIM" suppressempty="yes"> > <value field="AIM_HANDLE"/> > <parameter name="X-EVOLUTION-UI-SLOT" positional="no" show="no"> > <value field="AIM_SLOT"/> > </parameter> > </property> > > 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
