KMobile-driver = driving the device on the low-level,
KMobile client lib = giving one single linkable Library and DCOP-Interface to KDE applications
kmobile kioslave = "normal" kioslave functionality

you should implement the functionality you want to achieve within KitchenSync instead of adding yet another subdir/library/app to kdepim.

I'm quite sure that all functionality you need can be implemented within the existing frameworks.

Uh? I use camera:/ with any cammera

And KMobile can handle cameras, but at the same time PDAs, cell phones and other devices.

The "mobile:/" URL does work already with kio_mobile. Below it you will see your configured devices, one of which your camera model could be (e.g. a sub-folder named "Kodak DX4900" based on your freely choosed name and setup in KMobile). Clicking on this one can then bring up the folder named "pictures", or maybe just "Files".

...

Let's say it like this (with the kamera kioslave just as one example).

1. a) What functionality do you have now with the kamera kioslave ?
   • You can use kamera:/ to access files on all camera devices, which are supported by gphoto2.
   • This works directly from any application due to the fact that's a kioslave.
2. b) What functionality do you don't have yet ?
   • You don't have any syncronisation features - it's even more important for other device types.
   • You have to _know_ (!!), that kamera:/ is the kioslave for your camera... What is the URL for my scanner, mobile phone, rio player, ... ? Do all of those kioslaves support multiple devices, e.g. 2 different phones on the IRDA and USB ? Locking ? gphoto maybe, but I'm sure some of the other kioslaves maybe not.
   • Your device will not show up under devices:/, which would be logical.
   • The kamera-kioslave uses gphoto2, so all devices supported by gphoto2 are supported.

Good.
Now think of a completely new, yet unsupported device (maybe scanner, or e.g. a really old camera only working with a special ISA-card), in which you don't will get gphoto2 support. I know it's maybejust not believeable, but then you would need to write an additional driver. Which URL would you use for such a kioslave (kamera2:/, or mycamera:/, ???) How should the user know that ?

So, how could you solve that problems without loosing functionality ? ( I don't want to say, that it should be done. I'm just saying it might be done this way ! ) - You just drop some (small) pieces of the kioslave-related framework from the camera kioslave source. - you now have a kmobile device driver :-) - you will get syncronisation support at once for free with kitchensync and the kitchensync driver - you still have the "normal" kioslave support - it's for now just another URL (please keep reading on) - you can access your camera directly via kmobile:/ - any device, not only your camera - it will show up under devices:/ - you will see all your mobile/transportable devices showing up each by the other. - the user does not need to remember all different kioslave URLs, all kmobile-devices are accessible via kmobile:/<>

But, what would you loose with migrating to kmobile ? (Still, it's just an example!)

• You would loose the direct kamera:/ URL support

Is it possible to get a kamera:/ URL back again ?
Yes. Very simple. Just subclass the kmobile kioslave, make this kioslave handle kamera:/ URLs and let it only show up devices which have the "camera device" feature flag. This flag is provided by the kmobile (camera) device driver.

Just take a look at the skeleton driver in kmobile. It's like a normal kioslave - just with an unique interface on top of or using the kioslave framework.

Please take the discussion away from the kamera kioslave. The kamera kioslave has a good underlying infrastructure (gphoto2), which takes care of the most problematic issues like new devices in regard to kioslaves. This is often not the case for other devices. I don't know of many kioslaves for mobile phones, for Pilot, Zaurus or MP3-Players (the rio-kioslave seems somewhat broken atm).

The kmobile interface is universal and many kioslaves could be ported over from their current kioslave-only-centric state to the kmobile's (which is basically the same and makes porting really simple). So I'm not talking about "replacing" them, it's more to "integrate" them.

Does kmobile intend to do synchronisation or not?

No. My plan is, that Kitchensync will do that, and that Kitchensync will have with a kmobile-driver one single driver to access many mobile devices at once. The advantage with this concept is, that you don't need to write multiple drivers for kioslave/kitchensync-driver and import/export-filters for kaddressbook, kalendar, ...

"mobile:/" can be a one-start-point to many mobile devices at once. "kamera:/" could easily present only those devices which are camera- and camera-alike devices - you won't loose your "kamera:/" URL by that fact. One positive side-effect would be, that you would see camera-alike devices beeing supported even if it's support isn't yet in the current kamera:/ kioslave, but in another kioslave.

OK, it's just that kamera:/ came up in the thread. kioslaves are rare for this kind of mobile devices because they operate differently from many other devices on the system. Sure, cameras and mp3 players that show up as USB mass storage devices are fine - but you don't need a new ioslave for those anyway. But Pilots are unsuitable for kioslaves because of (a) their battery life (b) they start the communication, not the desktop. I don't have a Zaurus to comment on it.

This brings us back to your original motivation for KMobile: you don't just want to sync, you want to be able to access the data on the mobile device all the time. I think that desire deserves an argument all its own, but not in this thread. Anyway, you're trying to cut down code duplication by providing a single mobile-devices daemon that offers a DCOP interface to whatever is attached right now. Shuffle KS around a little and it interoperates, and then the DCOP interface is still available for whatever else wants to use it - like other ioslaves.

OK, I'm starting to see how this works: mobile:/camera/ shows me the cameras connected to the system, mobile:/camera/mltf100t/ shows my my F100, with the images that are in it (also available as file:/mnt/camera/dcim/mltf100t/, but that's another matter). mobile:/ipaq/addressbook/ shows something like the addresses on my (purely hypothetical) ipaq.

Ok, it's accessible easily if you know how to do it, but you have to set the mount permissions right, you need to mount them, and then you have them under file:/some_mount_point. I don't think this is intuitive for a nice desktop like KDE, and I'm pretty sure, that my father/mother won't handle it that easily like most expirienced Linux-users...

Pictures on cameras could be synced with kitchensync and kmobile, but often you want to access them directly. Addressbooks in phones or Pilots are maybe not that great to access directly via konqueror, but they are great for kitchensync. The combination of kmobile/kitchensync/kioslave/DCOP interface and shared library offeres all possibilities, just with single drivers and a common interface.

mobile:/ shows you all device icons (including one with a camera symbol and named as F100). If you click of mobile:/F100 you'll see sub-directories acording to the capatibilities of your device (e.g. Addressbook and a "Files"-Folder) mobile:/F100/Files (or: mobile:/F100/Pictures) will show you your pictures.

Just try the skeleton (the sample) driver yourself. E.g. compile kdepim/kmobile -> start up the "kmobile" application which is planned to be a daemon for the kicker sidebar (near the klipboard icon) and add the "Skeleton" Device. Then start up konqueror and go to "mobile:/", or just double-click on the Skeleton Icon.