'Re: [Kde-pim] network sync'

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

List:       kde-pim
Subject:    Re: [Kde-pim] network sync
From:       Mathias =?iso-8859-1?q?Fr=F6hlich?= <Mathias.Froehlich () web ! de>
Date:       2003-07-23 10:12:26
[Download RAW message or body]

Hi,

On Mittwoch, 23. Juli 2003 00:00, Cornelius Schumacher wrote:
> On Tuesday 22 July 2003 21:54, Martin Konold wrote:
> > I am wondering if either kpilot or kitchensync plans to integrate the
> > possibility of network sync.
>
> I'm working on a Konnector for KitchenSync which allows to sync with
> every iCalendar/vCard file you can reach via kioslaves.

Ok, I am talking about the addressbook file just as a placeholder.

I assume the most interresting case would be to sync
file:/home/schumacher/.kde/share/kabc/std.vcf
with
fish://notebook/home/schumacher/.kde/share/kabc/std.vcf

Or something like that.

How do you lock the addressbook database?

I think that we need a service/daemon on the other side doing the right 
things(TM). It also has to translate If one client uses an other backend 
database than the other one.

I have something in mind here. I have a half working IrMC Sync backend for 
kitchensync. I have also a full working OBEX folder browsing service 
kio_slave. I can now browse my filesystem on my mobile ;) And I have some 
code for an OBEX server.
Since kitchensync was (is?) not able to do syncs for some time I delayed this 
project a bit.
IrMC Sync works over the OBEX protocol. OBEX itself can use several transports 
including tcp/ip, IrDA, Bluetooth. You can also use any stream based 
transport you can imagine. Say, a serial cable or serial over USB, which is 
used to talk to a WinCE over USB (May be also possible to talk to familiar 
this way?).
OBEX has target services to connect to. When sending a OBEX connect you can 
send a target header with a special target uuid. When the server knows this 
target id it responds with something like "ok, I know what to do, send your 
requests".
This way IrMC Sync is seperated from the filesystem browsing service (FBS). If 
you connect to a server with the FBS target uuid you can browse the 
filesystem and put/get files, but you can't get the addressbook data. But If 
you connect with the IrMC Sync uuid to the same server you can sync your pim 
data but can not see the rest of the filesystem.
OBEX has a md5 digest authentication like HTTP has. No plain passwords in the 
air.

My server code was thought to test the client components 
(kio_slave/konnector). At the moment folderbrowsing works, a IrMC Sync server 
is on the way and uses given code (kabc) for access to a addressbook and 
converting adressees to vcards. This is far from beeing complete and has some 
problems with kde core libraries. But they are solvable.
And, since the obex library is only based on qt it will be not too much work 
to replace the kabc functions with opie pim access functions for use in opie.

So what can we do with that?
- First, be connective to several mobile devices over IrMC Sync. Which is 
itself able to transmit only incremental changes. Important for slow 
connections.
- Second, create our own OBEX service.

This service can be used to sync the pim data in a way IrMC Sync does. This 
has the advantage that the code for that is partly done. It will also be 
capable to stat files. I also think about the possibility to request rsync 
checksums from the server.

Advantages of this approach:
- Database files which are used to sync with can be locked and applications 
can be notified that something has changed.
- It does not matter which format the database has. Conversion to vcards is 
done by the server/client. (Since the vcard backend is the most flexible one 
in KDE one does not loose information if we are required to convert our data 
to vcards. Other pim data must be reviewed, I don't know much about vcal at 
the moment.)
- This holds also for mail folders. I have seen some discussion about a mail 
folder access library ...
- File syncronisation can be done this way.
- One can sync over many different transports using the same backend 
libraries. (For example OPIE over Bluetooth and your notebook over tcp/ip)
- The concept is extensible.

    Greetings

       Mathias Fröhlich

-- 
Mathias Fröhlich, email: Mathias.Froehlich@web.de

_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://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] 