-----Original Message----- From: Patrick Ohly [mailto:patrick.ohly@intel.com] Sent: Monday, July 11, 2011 10:10 AM To: Valluri, Amarnath Cc: SyncEvolution Subject: Re: Bug #11251 - notes synchronization On Fr, 2011-07-08 at 15:13 +0100, Valluri, Amarnath wrote: > I was looking this bug/feature : > https://bugs.meego.com/show_bug.cgi?id=11251, assigned to me. > > > > I spent almost two/three days to go through all the code related to > this, and XML configuration of data types etc. But couldn’t get enough > to start implementing the changes. No surprise, this issue touches on all of the Synthesis internals. Learning about those takes a while ;-) > My Understanding is : > > Currently ‘Note’ datatype is configured as ‘plain/text’ in synthesis > xml configuration with two fields, SUBJECT and TEXT. Hence it can’t > store additional fields like CATEGORIES of imported items. > > So we need to expand this datatype to accommodate whole Memo > information. Yes. But don't invent your own field list. Just use the existing "calendar" fieldlist. Then add a VJOURNAL sub-profile to the "vCalendar" mimeprofile. That'll enable synchronizing memos/notes as iCalendar 2.0, between peers which support that. Then change the "Note" textprofile so that it uses the "calendar" fieldlist. That should take care of conversion to/from plain text. > And even the text<->VJOURNAL conversion is happening in > backend(EvolutionMemoSource) which should be avoided. This conversion needs to be removed. EvolutionMemoSource itself probably becomes obsolete. > My Doubts are : > > > > i) you said in bug description that “configure > plaintext datatype which uses same field list as calendar”, But this > datatype is already existing, should we add fields to this? > > OR Can’t we have a sub-profile in Calendar profile as VJOURNAL ?, I > mean can we save memo’s also as calendar events L. The latter. > ii) I gone through SynthesisDBPlugin, SythesisEngine > and SyncSource code. But I couldn’t get exactly where and how these > configured datatypes/fields are being used in the engine side, > > while reading and writing the items. Have a look at SyncSourceBase::getDatastoreXML() in SyncSource.cpp. This is where the Synthesis XML config is being generated for each source. You'll find that it selects datatypes there. > iii) I am not clear How this type conversion to move > to Engine. and Say if we configure this type in engine, I hope we can > drop whole MemoSouce(.cpp) code. Am I right ? 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.

-----Original Message----- From: Patrick Ohly [mailto:patrick.ohly@intel.com] Sent: Monday, July 18, 2011 6:39 PM To: Valluri, Amarnath Cc: SyncEvolution Subject: RE: Bug #11251 - notes synchronization On Mo, 2011-07-18 at 14:12 +0100, Valluri, Amarnath wrote: > Hi Patrick, > > I did the following changes as per your suggestions: > > i) Added 'VJOURNAL' subprofile with suitable properties to calendar- profile.xml > > ii) Added a new datatype named 'journal' to notes-types.xml, whose basetype is 'vcalendar', and uses 'vCalendar' mimeprofile > <datatype name='journal' basetype='vcalendar'> > <use mimeprofile='vCalendar'/> > ..... You are leaving out the interesting part. Is there a corresponding text profile for that same field list? > iii) in SyncSource.cpp, getSynthesisInfo() added new branch to handle/use this new type : > else if (type == "syncevolution/journal") { > info.m_profile = "\"Note\", 2"; > info.m_datatypes = " <use datatype='journal' mode='rw' preferred='yes'/>"; > } I suspect that a second datatype <use datatype='journal-plain' mode='rw'/> is missing here. > iv) Handled this new mimetype('syncevolution/journal') in evolution backend, i.e, EvolutionCalendarSyncSourceRegister.cpp : > if (sourceType.m_format == "text/plain") return new EvolutionMemoSource(); > if (sourceType.m_format == "text/calendar" || sourceType.m_format == "syncevolution/journal") return new EvolutionCalendarSource(..TYPE_JOURNAL); Remove the EvolutionMemoSource(). It is no longer needed. > But I am not clear how to force this new data/mime type usage only for 'syncevolution' peers. You don't. For type == "syncevolution/journal" you tell the Synthesis engine that it is meant to support two external formats, iCalendar 2.0 and plain text. Internally both are stored in the same calendar field list. Towards the backend, the iCalendar 2.0 format is used. Towards the peer the automatic format negotiation picks the one supported by both peers. -- 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.

In the new VJOURNAL sub-profile your list VALARM. According to http://www.ietf.org/rfc/rfc2445.txt "4.6.3 Journal Component", a VJOURNAL must not contain VALARMs.

Please double-check the profile against the RFC. + <datatype name="journal-plain" basetype="text"> + <use profile="journal"/> + <typestring>text/plain</typestring> + <versionstring>1.0</versionstring> + <incomingscript><![CDATA[ + CALTYPE=2; //inform to script that, treat this as JOURNAL + $VCALENDAR_INCOMING_SCRIPT + ]]></incomingscript> + </datatype> The datatypes note10 and note11 exist for one and only one reason: there was some confusion in the SyncML community whether plain/text has mime version 1.0 or 1.1. Therefore Synthesis offers both and treats them internally exactly alike. We must replicate that with "journal-plain-10" and "journal-plain-11".

-----Original Message----- From: Patrick Ohly [mailto:patrick.ohly@intel.com] Sent: Wednesday, July 27, 2011 5:40 PM To: Valluri, Amarnath Cc: SyncEvolution Subject: RE: Bug #11251 - notes synchronization On Mi, 2011-07-27 at 15:22 +0100, Valluri, Amarnath wrote: > > >In the new VJOURNAL sub-profile your list VALARM. According to > >http://www.ietf.org/rfc/rfc2445.txt "4.6.3 Journal Component", a > >VJOURNAL must not contain VALARMs. > [Amarnath] Do you mean 'AALARM' and 'DALARM' properties in VJOURNAL sub-profile? Yes. It looks like a cut-and-paste from some other sub-profile. That's a good start, but we need to double-check which of these properties really can occur in a VJOURNAL. -- 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.