[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Project proposal
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2004-07-21 16:58:11
Message-ID: 200407211858.11637.schumacher () kde ! org
[Download RAW message or body]

On Wednesday 21 July 2004 18:22, Armin Bauer wrote:
> On Wed, 2004-07-21 at 13:21, Cornelius Schumacher wrote:
> >
> > The problem I see is with the representation of the data.
> > Abstracting the process of syncing in a language-independent way is
> > certainly possible, but how do you pass the data between the
> > application and the plugins?
>
> One possible way to do this is to define one protocol for each format
> we want to sync. For example vcard or syncml or our own protocol for
> contacts. Another one for mail etc. The opensync project would then
> take care of choosing a good protocol.

You are talking about formats not protocols, right? Transport protocols 
are probably what is quite easy to encapsulate in a common plugin 
concept. SyncML would probably also qualify as transport protocol. But 
formats are much harder as they demand a lot of detailed knowledge by 
the application. All applications using the format have to interpret 
all its fields in the exactly same way. In addition to that passing 
data between plugins and applications using a textual representation 
like vCard is highly inefficient.

> > Inside of a framework like KDE the answer is simple because there
> > are existing classes representing the data. There is no question
> > how to represent a string object etc. But doing this in a
> > language-independent way would require lots of wrapper and
> > converter code, so that the benefit of a common plugin interface
> > becomes questionable.
>
> Of course you would have to write a converter for each one of these
> protocol to parse it into the KDE format. But how do you internally
> handle contacts? Arent they vcards too?

vCard is a storage format. One of several possible formats. Internally 
this is of course represented as an object in memory with an API to 
access its data. That's independent of the storage format.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]