[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:       Holger Freyther <freyther () gmx ! net>
Date:       2003-04-23 8:43:14
[Download RAW message or body]

Ok 4th try this time without trying to reply... my kmail is somehow fscked up 
and refuses to send email. The mail is inside Mail/sent-mail/... but it's not 
shown inside the GUI....

On Wednesday 23 April 2003 07:47, Helge Deller wrote:
some how kmail lost the my reply... did not send it

short: IMHO libkonnector2 == (libkmobile - generic stuff - debuged - 
extendable)
I would prefer if you would work on libkonnector2 because it is meant to be 
the transport layer. The additional sync overhead in the Syncee/SyncEntry 
generic container and inside the Qtopia Konnector is not necessary for Gnokii 
if it only wants to provide simple im and export. It does not need to provide 
sync support! It can though!
KitchenSync supports two sync modi.
MetaLess and MetaMode:
MetaMode collects all the changes made so it only needs to sync modified 
entries and delete deleted.
The MetaLess mode is basicly what you want for import and export ( default 
mode ). It basicly fetches a file from the device package it up into 
something KDE understands and emits a signal. and it does the opposite on the 
way back.
You can even implement that via the startSync stuff when fetching and querying 
is not implemented inside the backend...

> > > The idea:
> > > 	- write a universal/generic plugin system (e.g. "class
> > > KMobileDeviceManager") - for every mobile device write a access-driver
> >
> > KonnectorManager
>
> Yes, something like this is needed.
it does exist. You can query for installed plugins. Configured devices are 
only known to the GUI but this can be changed. 

> It's definitively usable inside KDE. It's goal is to do clean
> syncronisation, but I'm thinking of an easy way to connect devices, select
> some (a single) data structure (file, contact or calendar entry), drag&drop
> it from konqueror to kaddressbook or kcalendar and import/export it that
> way graphically. This is not about syncronisation, it's about moving
> information.
KAddressbook Import via libkonnector2 + some stuff from the GUI:
A)Show dialog with configured devices. Select one query it for 
AddressBookSyncee, get AddessBookSyncee. Show Addressees let the user select 
some and import them
B)Having IO Slave. Show list of loaded devices ( communicate with KitchenSync 
GUI DCOP ). Query device for what it supports. User changes dir into 
Addressbook. Fetch addressbook and put short names into UDSEntry start drag 
'n drop....

so both things are possible even with libkonnector2 but in a generic way! A 
can be implemented today ( using startSync cause query is not yet implemented 
) B needs DCOP Iface for KitchenSyncMainWindow but is doable too.
>
> Think about my mobile phone. I come with my mobile phone to your laptop,
> it's automatically detected, we drag 3 different phonebook-entries from it
> into your addressbook and ignore all others. With kitchensync you would
> need to syncronize all entries at once. At the same time I connect my mp3
> player to your laptop and copy 2 of my files to your machine. Directly.
> Then I drag one other song from any of your directories onto my player.
> This is how I would like it to work later on a common interface for all
> types of mobile devices, and this is not what kitchensync is intended for.
same as above. Just do not save meta data. And KitchenSync works with any kind 
of information thanks to Cornelius Syncee/SyncEntry approach. One of his 
goals was to provide a flexible generic api but that implementations do not 
need to implement much.
>
> I hope you see that libkmobile will not be a clone or another
> implementation of kitchensync. It just does a different job, but if I write
> a libkmobile plugin for kitchensync you will get the advatages of both
> solutions without any syncronisation problems.
I still think libkonnector2 is more generic and suitable for your thoughts but 
if you think the fragmentation and specilisation/limitation is needed. I 
would prefer you to work on libkonnector2 put it's your limited free time and 
if you think libkmobile is valuable it's your decision and I wish you good 
luck.

kind regards Holger

>
> Regards,
> Helge

-- 
_____________________________________________
Holger 'zecke' Freyther
developer
Project OPIE- the Open Palmtop Integrated Environment
http://opie.handhelds.org | http://www.opie.info (german)
IRC: irc.freenode.net #opie #opie.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]