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

List:       kde-pim
Subject:    Re: [Kde-pim] RFC ideas for syncing with mobile units
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2001-12-03 16:51:18
[Download RAW message or body]

On Thursday 29 November 2001 20:20, Holger Freyther wrote:
> Am Donnerstag, 29. November 2001 15:42 schrieb Cornelius Schumacher:
> Hi Cornelius, all,
>
> > On Tuesday 27 November 2001 15:11, Holger Freyther wrote:
> > > Hi kdepim people,
> > > hi all I bought a vr3 from agenda computing. And now I'm thinking of a
> > > common way of syncing with apps. I saw kitchensync but I think the
> > > design got some problems.
> > > I came up with my own design. It's attached at this email. It's
> > > currently just a rough draft but I'm going to develop it.
> >
> > Did you have a look at ksync (see http://pim.kde.org and kdepim/ksync in
> > CVS)? This aims at providing a general architecture for syncing. I think
> > at least parts of your proposal are already covered by this.
>
> I looked at it and yes some parts are really the way I wan't it to be.
> Specially the syncing stuff ( merging, duplicated check..). I also like the
> way with the xml files. Even if I currently don't know how to do this. I
> thought plugins could export its' one functions over dcop. So there would
> be a way for plugins to have non standards methods.

Which XML files do you mean?

Regarding plugins: Usually the meaning of "plugin" is something like "an 
implementation of an abstract interface loaded dynamically at run-time". That 
means that a plugin is becoming part of the process it is plugged into. So 
DCOP will not work, because DCOP is about interprocess communication. What 
you need is something like the editor framework in kdevelop, where a class 
has functions to tell what kind of interfaces it supports.

> > To have one single application (you shouldn't call it libsync, if it
> > isn't a library, by the way) for communicating with all kind of devices
> > is very ambitious, even with the plugin concept. I think the first step
> > would be to use the existing apps like kpilot and kandy and make them
> > work together with ksync. More integration can come later, when this
> > works.
>
> true. This was because of historical reason.

You would it make it easier for us to get your concept, if you would change 
the name :-)

> Actually I want to go for the big thing. I think it won't fit in kde3.0 but
> maybe it'll be finished for kde3.1 or even later. It think it's the best
> way. It's better than trying to extend some stuff with the need of not
> breaking bic during it's lifetime ( reminds me to get something like the
> interfaces from com+ ). I think my approach will be a lot cleaner when it's
> finished. Currently I'm creating container classes for todo, schedule...
> and trying to get the dcop sending to work. And I'm also learning how to
> synchronize with my agenda (it's using rsync over ppp as far as I know ).
> I'm trying to reduce code duplicity in kde-pim along with syncing and other
> stuff. As a side effect we would gain a common format to synchronize
> todo... between apps.

Binary compatibility is currently not an issue. It might become important, if 
we have stable syncing libs, which are also used outside of KDE, but as long 
as we provide syncing functionality within kdepim, we don't have to care 
about this.

What's so bad about the current stuff, that you want to throw it away and 
start from scratch? I think it makes much more sense to build on the existing 
code. Having something, which is at least basically running, is essential to 
allow collaborative work on this stuff and I think it's very important that 
we all work together to achieve a decent syncing infrastructure for KDE. A 
single person on its own will not succeed, I'm sure.

The agenda comes with a tool, which syncs with existing vCalendar files. The 
missing part of synchronisation is the communication with the KDE apps like 
KOrganizer or the KDE addressbook. Rewriting the stuff communicating with the 
agenda is, in my opinion, a waste of time. Let's first get syncing working 
and then improve it. Rewriting existing stuff, will not bring us further.

There already is a common format for todos. It's iCalendar. There a classes 
in libkcal to handle todos and more. There is no need to rewrite these 
classes. If there is missing something, we should fix the existing code, not 
writing new code, which will be broken in other areas.

> > Another comment: Using DCOP to exchange all the data, which has to be
> > synchronized, might not be a good idea. DCOP is not meant for exchanging
> > large volumes of data, this will not be very efficient.
>
> Maybe true. I read the dcop manuals and they note that sending QByteArrays
> larger than 2mb was really poor but they solved this problem. But what
> we're talking about 20-40 notes max, to-do at a time maybe twenty too? That
> really isn't much. Syncing is not really a time critical task.

Ok, you might be right, that perofrmance is not the problem, but what's the 
advantage of using DCOP to exchange data over direct function calls in a 
single program or using files?

> With my approach someday there could be a program that syncs knewsticker
> entries with the pda.

Yes, syncing should become much more general. That's t he basic idea behind 
ksync.

> PS: I would like to know which parts do you like, dislike. And what will
> happen if I get it working. Is there a possibility of integration in
> kdepim?

You could integrate it from the beginning on by working on the existing stuff 
instead of doing a parallel implementation of what already is there. The code 
is already there. Just use it.

Don't get me wrong. I'm not saying that you shouldn't work on your project, 
but I think that it is very similar to what we already have planned and 
started in kdepim, so I would be happy, if you would join us in developing 
the KDE syncing architecture.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim

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