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

List:       kde-pim
Subject:    Re: [Kde-pim]  [RFC] libkmobile - A Universal Mobile Devices
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2003-04-24 9:57:10
[Download RAW message or body]

On Wednesday 23 April 2003 08:12, Helge Deller wrote:
> > > The idea:
> > > 	- write a universal/generic plugin system (e.g. "class
> > > KMobileDeviceManager") - for every mobile device write a
> > > access-driver based on a "KMobileDevice" class (sample code example
> > > attached below),
> >
> > The attached interface seems to be a bit limited. It isn't very
> > extensible in terms of data types. I think such a library should focus
> > on abstracting the transport level and leave handling of data types to
> > something independent of transport.
>
> I disagree.
> Applications need datatypes they can directly use and work on.
> And this is currently only the KDE object datatypes.
> This is even more important, if you want to handle different devices
> with one single interface.

I didn't say that applications don't need datatypes. Quite the contrary, 
applications only need datatypes and nothing else. Applications shouldn't be 
bothered with transport of data.

> > > Since my time in general is very limited, I definitively would need
> > > help from others on such a project.
> > > Personally I would like to start with an implementation with gnokii
> > > and gammu to make most mobile phones directly accessible.
> > > If people don't complain, I would like to create the subdirectory
> > > kdepim/libkmobile and put my initial work there.
> >
> > Why don't you add gnokii and gammu support to KitchenSync?
>
> I started it.
> But then I realized, that I would need to add gammu/gnokii support for
> every single application (kitchensync and/or kandy for syncing;
> kaddressbook, kcalendar, ... for import/export).

No. The idea of KitchenSync is exactly to avoid this kind of problems. A 
Konnector implements the transport layer for all kinds of data. So you only 
need one gnokii konnector which handles data for all applications.

> And I would need a new
> driver for every of my other organizers and other devices.

If they use a different transport mechanism then you have to write a different 
Konnector. There is no way around that.

> One simple thing would be to have a
> digi-cam or mp3-player driver for libkmobile, where you can directly
> drag&drop your pictures around.

This already works quite well in Konqueror.

> As I said in my other mail, if nobody complains I would like to start
> hacking on libkmobile (in kdepim/libkmobile) and make it excluded from
> compilation by default. One goal is of course to write a plugin for
> kitchensync. This plugin would use libkmobile and should solve the possible
> syncronisation problems you mentioned above.

As said before, I would prefer if you would implement your ideas inside of 
KitchenSync. I'm sure that this is the right place. There might be changes in 
KitchenSync necessary, but that's not a problem. We can discuss that and 
implement it in a way that fits all our needs.

-- 
Cornelius Schumacher <schumacher@kde.org>

_______________________________________________
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]