On Wed, 2012-08-15 at 09:16 +0200, [email protected] wrote:
> Patrick Ohly <[email protected]> wrote on Wed, 15 Aug 2012 08:51:20
> +0200:
>
> > Justus, can you redo the logs after setting loglevel=4 in your sync
> > config?
>
> Done; you find the logs at the same place.
Okay, got it. I could reproduce the problem with a file source that is
configured to use databaseFormat=text/calendar+plain. That was meant to
store as iCalendar 2.0, but ended up with items which have VERSION:1.0
and iCalendar 2.0 encoding rules.
Copying Lukas, because I'm not entirely sure what the proper fix is. I
have a patch which "works for me".
Lukas, the problem here is that the Synthesis engine is used to convert
a plain text memo to iCalendar 2.0 in the local storage. This is done
like this:
- define a text datatype which uses the same field list as calendar
data:
<textprofile name="JournalText" fieldlist="calendar">
<linemap field="SUMMARY">
<numlines>1</numlines>
<inheader>false</inheader>
<allowempty>true</allowempty>
<filterkeyword>SUMMARY</filterkeyword>
</linemap>
<linemap field="DESCRIPTION">
<numlines>0</numlines>
<inheader>false</inheader>
<allowempty>true</allowempty>
</linemap>
</textprofile>
<datatype name="journaltext10" basetype="text">
<use profile="JournalText"/>
<typestring>text/plain</typestring>
<versionstring>1.0</versionstring>
...
same for text/plain 1.1
- The "calendar" profile was extended to support VJOURNAL.
- The incoming script of "journaltext10" sets ISEVENT in
the "calendar" field list so that the data is marked as "journal".
- define a store which supports iCalendar and plain text:
<use datatype='icalendar20' mode='rw' preferred='yes'/>
<use datatype='journaltext10' mode='rw'/>
<use datatype='journaltext11' mode='rw'/>
The problem that Justus ran into is this:
1. A text/plain item from the peer is parsed and turned into
an item with TTextItemType (corresponds to "journaltext10").
2. Before writing into the local storage,
MAKETEXTWITHPROFILE("vCalendar", 2) is called.
3. For the value of VERSION, that method calls
TTTextItemType::getTypeVers() =
TSyncItemType::getTypeVers(), which returns the configured
1.0 (from "journaltext10").
4. The backend fails to parse the generated item because it
only supports iCalendar 2.0 and is given something which
has VERSION:1.0.
My "fix" is to extend TTextItemType specifically for the case where
getTypeVers() is called with a non-zero mode. I checked the source, that
should only happen when used in combination with a MIME profile,
something which only SyncEvolution does. I had to hard-code the support
for iCalendar 2.0 (aMode = 2) and vCalendar 1.0 (aMode = 1), something
that does not really belong into TTextItemType. Is there a better
solution? Patch below.
I was suspicious about a similar problem for the iCalendar 2.0 ->
text/plain conversion. The item sent to the phone only has text/plain in
the meta data, but no version:
<Meta><Type>text/plain</Type></Meta><Item><Source><LocURI>14</LocURI></Source><Data>...
However, items using the traditional text datatypes (EDS backend at the
moment) are also sent without a version in the meta data, so that is
probably okay. DevInf is correct.
diff --git a/src/sysync/textitemtype.cpp b/src/sysync/textitemtype.cpp
index 09aeb69..3ba4fa9 100755
--- a/src/sysync/textitemtype.cpp
+++ b/src/sysync/textitemtype.cpp
@@ -157,6 +157,23 @@ TTextItemType::~TTextItemType()
delete fProfileHandlerP;
} // TTextItemType::~TTextItemType
+cAppCharP TTextItemType::getTypeVers(sInt32 aMode)
+{
+ // This function is called by TMimeDirProfile when generating the
+ // VERSION property. Allow converting a plain text item to
+ // iCalendar 2.0 (aMode = 2) or vCalendar 1.0 (aMode = 1) by
+ // overriding the base version that was configured for the
+ // underlying text item type.
+ switch (aMode) {
+ default:
+ return inherited::getTypeVers(aMode);
+ case 1:
+ return "1.0";
+ case 2:
+ return "2.0";
+ }
+} // TTextItemType::getTypeVers
+
#ifdef OBJECT_FILTERING
diff --git a/src/sysync/textitemtype.h b/src/sysync/textitemtype.h
index 4240f4b..5dac68a 100755
--- a/src/sysync/textitemtype.h
+++ b/src/sysync/textitemtype.h
@@ -61,6 +61,7 @@ public:
// destructor
virtual ~TTextItemType();
// access to type
+ virtual cAppCharP getTypeVers(sInt32 aMode=0);
virtual uInt16 getTypeID(void) const { return ity_text; };
virtual bool isBasedOn(uInt16 aItemTypeID) const { return
aItemTypeID==ity_text ? true : TMultiFieldItemType::isBasedOn(aItemTypeID); };
// differentiation between implemented and just descriptive TSyncTypeItems
--
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
