Re: [Opensync-devel] akonadi-sync (discussion)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Chris Frey wrote:

> On Sat, Sep 18, 2010 at 12:40:36PM +0200, deloptes wrote:
>> The thing is that I'm not sure where to do it and what type of format and
>> objtype I need to set - or do I need a proper configuration file?
> 
> I'm definitely not an Akonadi expert, but if the types change per
> installation, this should be taken into account in discover.

The kde user can define different backends and multiple ressources
(collections) per item (calendar, contact, etc)
How is this to be represented in the config? The config is used for
discovering and syncing right? (read further)

> 
> Also, each type can be enabled and disabled in the plugin config.
> This is handled by the engine, although the plugin can make use of it.> 
> If both are "true" (for example, if Akonadi supports events and events
> are enabled in the plugin config), then that type can be enabled in
> the discover process.

So in discover it should search (and set) the corresponding type (and
format?) for the discovered akonadi ressource. This was not done in the
original code but rather it filters only contact and event from the
resources found in akonadi. Briefly discover iterates over the config items
searching for possible akonadi support and skips all that was found but is
not in the config.

The question is 
- Do I need to put the things I want to discover (and sync) in the config or
- Do I need to rewrite the features in the config (which features) was
discovered or extend the config with new ressources that were discovered

So I'm proposing a way below which I think is ok, and I'll check in the code
later today.

> 
> I'm afraid I'm not explaining this very well.  Let me know if you have
> more questions.

It is fine. I need to get an impression how the config is (to be) used.
Thanks for explaining.

> 
> 
>> the file plugin i.e. could be used to sync "Local Folders" and may
>> be "outbox" too
>> 
>> [1284801554.297273]             FORMAT: vcard21
>> [1284801554.297299]             FORMAT: vcard30
>> [1284801554.297320]             FORMAT: vevent10
>> [1284801554.297339]             FORMAT: vevent20
>> [1284801554.297358]             FORMAT: vtodo10
>> [1284801554.297377]             FORMAT: vtodo20
>> [1284801554.297396]             FORMAT: vjournal
>> [1284801554.297415]             FORMAT: vnote11
> 
> This depends on what format of data you get from Akonadi.
> Can you extract RFC format data from it?  If so, then these are what
> you want.

So I need to check in discover for supported format and set the objformat
for the ressouse. This is what I'll be doing next.

> 
> 
>> [1284801554.297435]             FORMAT: xmlformat-contact
>> [1284801554.297457]             FORMAT: xmlformat-event
>> [1284801554.297476]             FORMAT: xmlformat-todo
>> [1284801554.297496]             FORMAT: xmlformat-note
> 
> Opensync has its own xmlformat for these types, and converts the
> RFC formats into XML internally.  These same XML documents, in
> binary parsed form, can be passed to the plugin, and used
> via the osync xml and xmlformat APIs.  This saves the need for
> parsing.
> 
> 
>> [1284801554.297515]             FORMAT: xmlformat-contact-doc
>> [1284801554.297535]             FORMAT: xmlformat-event-doc
>> [1284801554.297563]             FORMAT: xmlformat-todo-doc
>> [1284801554.297582]             FORMAT: xmlformat-note-doc
> 
> If what you want is the actual XML, then you want the doc, in text.
> If you need to work with the data, you'll need to parse it with
> libxml yourself, or use the osync xml API.  Alternatively, you
> can use XSLT to transform the XML into something that Akonadi can
> use, and vice versa.
> 
> 

Thanks for explaining. this was good to know

>> [1284801554.297622]             FORMAT: file
>> [1284801554.297642]             FORMAT: plain
>> [1284801554.297661]             FORMAT: memo
> 
> I hardly use these, but I believe the file and plain formats are
> mostly used for backups.
> 
> 
> In case you're looking for examples:
> 
> The barry-sync plugin uses the vformat formats (first choice).  It
> actually goes to great lengths to create and parse these formats,
> using some of the vformat API copied from opensync itself.
> I would not recommend going this route, since you need to get
> deep into the RFC details sometimes, but if you get data from
> Akonadi in this format, then don't parse it yourself...
> pass it straight into opensync, and let opensync deal with it.

The barry-sync is not exactly what I need as it does process standard items.
In aconady items are multiple collections of data. So I see a potential
danger here. If I sync my calendar from kde with my phone. In kde I have 1
moonphase calendar defined and multiple other calendars, like holidays,
private and public. Who is this to be managed in opensync?

I read about akonadi items - they are identified by mimetypes, so this is
may be the best way to check them. So I'll probably need the mime option
and some advanced options in the config to get several subtypes in one
collection i.e. "Address Book" and assign multiple ressources. How do I do
this? barry does not show a way

> 
> The google-calendar uses the 3rd method, taking the -doc formats
> and using xslt to transform them into something that Google accepts.
> I'm no XML guru, so this has been a challenge at times too (mostly
> due to learning Google Calendar XML API on the fly.)
> 

I'm not sure what akonadi can do right now. I think it supports different
types and you can get one on a request i.e (vard, vevent etc).

For now its important to know what I should have in the config file to get
i.e. a syncml phone sync with akonadi.

I imagine and do following

1. configure group with syncml, akonadi member
2. configure each member to default (--configure group 1/2 + save)
3. discover supported features and objtypes (here I expect both to write
additional information into the config) by running with --discover
4. reconfigure if necessary (choose what to sync)
5. sync

this means I can provide a config for contact, todo, note, journal,
calendar .
akonadi-plugin would match these ressources to it's own and the user will
decide what to sync and can configure respectively.

The other way to go would be to skip the config entirely (like in kde3) and
let the plugin configure itself by writing the config file when run
with --discover. Then the user would configure what needs to be synced.

however I do a mix, like in syncml ... provide only one ressource "contact"
and let the engine do the rest

it looks like this

akonadi_opensync(3803) akonadi_discover: found 4 collections
akonadi_opensync(3803) akonadi_discover: available resource for "Address
Book" ("text/directory", "application/x-vnd.kde.contactgroup")
akonadi_opensync(3803) akonadi_discover: available resource for "outbox"
("message/rfc822", "inode/directory")
akonadi_opensync(3803) akonadi_discover: available resource for "Local
Folders" ("message/rfc822", "inode/directory")
akonadi_opensync(3803) akonadi_discover: available resource for "Search" ()
akonadi_opensync(3803) akonadi_discover: using resource contact for "Address
Book" ("text/directory", "application/x-vnd.kde.contactgroup")
akonadi_opensync(3803) akonadi_discover: creating resource for "outbox"
("message/rfc822", "inode/directory")
akonadi_opensync(3803) akonadi_discover: creating resource for "Local
Folders" ("message/rfc822", "inode/directory")
akonadi_opensync(3803) akonadi_discover: osync type  contact
akonadi_opensync(3803) akonadi_discover: osync type  Address Book
akonadi_opensync(3803) akonadi_discover: osync type  outbox
akonadi_opensync(3803) akonadi_discover: osync type  Local Folders
akonadi_opensync(3803) akonadi_finalize:
Discovered Objtypes:
        Address Book
                No formats found: (null)
        outbox
                No formats found: (null)
        Local Folders
                No formats found: (null)
Discovered Objtypes:
        contact
                Format: vcard21
                                 conversion config:
VCARD_EXTENSION=Evolution
                Format: vcard30
                                 conversion config:
VCARD_EXTENSION=Evolution
        event
                Format: vevent20
        todo
                Format: vtodo20
        note
                Format: vjournal

This results in following xml file

<?xml version="1.0"?>
<config version="1.0">
  <Resources>
    <Resource>
      <Enabled>1</Enabled>
      <Formats>
        <Format>
          <Name>vcard30</Name>
        </Format>
      </Formats>
      <Name>Address Book</Name>
      <ObjType>Address Book</ObjType>
      <Url>akonadi:?collection=4</Url>
    </Resource>
    <Resource>
      <Enabled>1</Enabled>
      <Formats>
        <Format>
          <Name></Name>
        </Format>
      </Formats>
      <Name>outbox</Name>
      <ObjType>outbox</ObjType>
      <Url>akonadi:?collection=3</Url>
    </Resource>
    <Resource>
      <Enabled>1</Enabled>
      <Formats>
        <Format>
          <Name></Name>
        </Format>
      </Formats>
      <Name>Local Folders</Name>
      <ObjType>Local Folders</ObjType>
      <Url>akonadi:?collection=2</Url>
    </Resource>
  </Resources>
</config>

in the original code the format was simply hardcoded and not guessed,
something I'm working on at the moment.

thanks a lot for the patience.
I'm not used to writing that long mails  but I need some more details to
make the best I can and save time.

kind regads