GNOME Bugzilla – Bug 456259
Add get/set for PIM through D-Bus
Last modified: 2018-08-17 18:48:52 UTC
For Conduit to use. It should allow to get/set: - Contacts - Calendar items (appointments) - Todo items - Notes
Any movement or direction on this? Now that conduit has a glib binding library, controlling it from C apps should be a breeze.
(In reply to comment #1) > Any movement or direction on this? > > Now that conduit has a glib binding library, controlling it from C apps should > be a breeze. I would actually prefer doing this the other way around. I don't want any synchronising code in gnome-phone-manager itself, and I'd rather conduit used gnome-phone-manager, rather than the opposite. I would also like if you could tell me what a good API would be for the D-Bus service offered by gnome-phone-manager. I don't really have any preferences on how to offer the data, but I guess spec-compliant vCards, vCals, etc. would be my preferred choice.
(In reply to comment #2) > (In reply to comment #1) > > Any movement or direction on this? > > > > Now that conduit has a glib binding library, controlling it from C apps should > > be a breeze. > > I would actually prefer doing this the other way around. I don't want any > synchronising code in gnome-phone-manager itself, and I'd rather conduit used > gnome-phone-manager, rather than the opposite. = Discovery = Completely agree. I would like to use gpm as a means to discover phones are connected, and to get information about the phone. Kind of like HAL for phones. Conduit would then use this info to select what would be the most appropriate way to sync PIM data off the device, and to pre-configure other things to sync (such as videos, photos, etc) I could then get PIM data off the phone by * using Gammu * using libsyncml * using gpm directly (see below) > > I would also like if you could tell me what a good API would be for the D-Bus > service offered by gnome-phone-manager. I don't really have any preferences on > how to offer the data, but I guess spec-compliant vCards, vCals, etc. would be > my preferred choice. = Getting Data = Background/Requirements: 1. The steps above would need to return some sort of immutable ID for the phone. Its phone number, IMEI number, etc (I will call this phoneId) 2. Each piece of data from the phone needs to be capable of being represented by another immutable ID. OK, its not necessary that its completely immutable and unchanging between all times the phone is connected, but it makes things a heap easier. (I will call this dataId) Then a suitable,minimal API would look like * method(signature) --> return type typedef enum { TYPE_CONTACT, TYPE_TODO, TYPE_CALENDAR, } PhoneDataType * get_all(phoneId p, PhoneDataType t) --> (list of dataIds) * get(phoneId p, PhoneDataType t, dataId d) --> A vCard, or iCal (if its a contact, calendar) --> raw text if its unstructured data like a TODO list nb: Could also implement as get_{contact,todo,calendar,etc}(phoneId p, dataId d) * put(phoneId p, PhoneDataType t, data d) --> the dataId of the stored data nb: data could be vCard, iCal, or raw text, what ever is easiest/most appropriate nb: Could also implement as put_{contact,todo,calendar,etc}(phoneId p, data d) * delete(phoneId p, data d) --> True if successful Thats the minimal set of functions (if I remembered correctly). There are other convenience functions that may improve things like * data_exists(phoneId p, dataId d) There are also two ways to minimise the amount of data Conduit must get from the phone in order to work out what has changed (in a phone --> something else sync) 1. Implement some sort of transaction support * get_changed_data(phoneId p, PhoneDataType t, magicNumber m) --> three lists of dataIds, added, modified and deleted * finish() --> a magic number to be used next time with get_changed_data 2. Implement helper functions to return data information. For example, in the simplest implementation, conduit will get all data from the phone, hash it to work out what has changed, and then transfer that to the thing synced with. This can be avoided by implementing something like * get_{mtime, hash}(phoneId p, dataId d) --> some string But its a compromise. Its often easiest to do a simple implementation at the C end and do all the hard stuff in python. So the net result would be Excuse cruddy ASCII UML ----> data flow over dbus | | | \/ time Connect Phone Phone Connected Signal ------------> Conduit .....................................Conduit Inits GPM Dataprovider .....................................(written in python) GPM.get_all() ---------------------> Conduit Gets UID of all data GPM.get() -------------------------> Conduit Gets all data .....................................Conduit puts new data into other .....................................dataprovider GPM.put(data) <--------------------- Conduit puts new data to phone Hope that makes sense. If you want to return raw xml/strings from the phone over dbus then thats fine. Its just as easy to turn them into vCards in the Conduit end. We just need to agree what those strings will look like.
The complexity of the 'getting data' section depends directly on * How comfortable you are with me using gammu (bacause it has python bindings) instead of gnokii to interface with the phone * Whether multiple programs on the host PC (conduit and GPM) can be in communication with the phone at once (eg in the case of using the serial port profile and AT commands to get PIM data). If not, then all comms will need to go through GPM
(sorry for SPAM). Oh, and the point of conduit-glib is that if you want to have a big "Sync" button in GPM, then this would then use conduit-glib to tell conduit to start the sync process described in my horrible data flow ascii diagram It would also preconfigure some things, like if you wanted to add a "Sync Photos" button, then this would configure conduit (using conduit-glib over dbus) to setup and run a synchronization between the phone (using obex-ftp) and $ONLINE_PHOTO_SITE Of course all of this could also be done from within the Conduit GUI, but its up to you.
(In reply to comment #4) > The complexity of the 'getting data' section depends directly on > * How comfortable you are with me using gammu (bacause it has python bindings) > instead of gnokii to interface with the phone I'm more comfortable with gnokii itself. We fixed a lot of bugs in gnokii > * Whether multiple programs on the host PC (conduit and GPM) can be in > communication with the phone at once (eg in the case of using the serial port > profile and AT commands to get PIM data). If not, then all comms will need to > go through GPM Only one program can connect to the phone at a time, so yes, most things should be going through gnome-phone-manager instead of doing their own things.
(In reply to comment #3) <snip> > Conduit would then use this info to select what would be the most appropriate > way to sync PIM data off the device, and to pre-configure other things to sync > (such as videos, photos, etc) gnokii (and AT commands) can only be used to sync "PIM" data (contacts, calendars, and addressbook). > I don't really have any preferences on > > how to offer the data, but I guess spec-compliant vCards, vCals, etc. would be > > my preferred choice. I'll probably need to update gnokii to use the correct fields. Do you have links to the specs? > = Getting Data = > > Background/Requirements: > 1. The steps above would need to return some sort of immutable ID for the > phone. Its phone number, IMEI number, etc (I will call this phoneId) We get and store the IMEI now. > 2. Each piece of data from the phone needs to be capable of being represented > by another immutable ID. OK, its not necessary that its completely immutable > and unchanging between all times the phone is connected, but it makes things a > heap easier. SyncML offers UUIDs, but reading using AT commands only offers things like: X-GSM-MEMORY:ME X-GSM-LOCATION:2 Which aren't constant across runs (it's possible to delete a contact, and all the indices are then shifted. But we can fake a not that good UUID with those I guess. > (I will call this dataId) > > Then a suitable,minimal API would look like > > * method(signature) > --> return type > > typedef enum { > TYPE_CONTACT, > TYPE_TODO, > TYPE_CALENDAR, > } PhoneDataType > > * get_all(phoneId p, PhoneDataType t) > --> (list of dataIds) Should be easy. > * get(phoneId p, PhoneDataType t, dataId d) > --> A vCard, or iCal (if its a contact, calendar) > --> raw text if its unstructured data like a TODO list Todo items could use vNotes. > nb: Could also implement as > get_{contact,todo,calendar,etc}(phoneId p, dataId d) OK. > * put(phoneId p, PhoneDataType t, data d) > --> the dataId of the stored data > > nb: data could be vCard, iCal, or raw text, what ever is easiest/most > appropriate > > nb: Could also implement as > put_{contact,todo,calendar,etc}(phoneId p, data d) OK. > * delete(phoneId p, data d) > --> True if successful OK. > Thats the minimal set of functions (if I remembered correctly). > > There are other convenience functions that may improve things like > * data_exists(phoneId p, dataId d) It's just as quick getting the data as it is checking that it's there, so should I implement this? > There are also two ways to minimise the amount of data Conduit must get from > the phone in order to work out what has changed (in a phone --> something else > sync) > 1. Implement some sort of transaction support > * get_changed_data(phoneId p, PhoneDataType t, magicNumber m) > --> three lists of dataIds, added, modified and deleted > * finish() > --> a magic number to be used next time with get_changed_data > 2. Implement helper functions to return data information. For example, in the > simplest implementation, conduit will get all data from the phone, hash it to > work out what has changed, and then transfer that to the thing synced with. > This can be avoided by implementing something like > * get_{mtime, hash}(phoneId p, dataId d) > --> some string I'm afraid that we wouldn't be able to do any better than Conduit would there. The amount of data would probably run in 100k, rather than megs for everything that we can get on the phone, so Conduit is probably better off doing that at its end.
Created attachment 112662 [details] [review] First version of the backend API Depends on a patch I posted to the gnokii list yesterday, not yet committed. I tested the phonemgr_listener_list_all_data() and phonemgr_listener_get_data(), delete should work, put doesn't work (I need to unbreak some gnokii stuff first). Could you tell me whether the API in phonemgr-listener.h resembles something you'd like, or does it need more error checking/errors? Note that I only implemented contacts because that's the only thing that works with the AT driver.
Created attachment 112850 [details] [review] Updated patch This should fix the _put() function. _list_all_data() needs more work.
> > Thats the minimal set of functions (if I remembered correctly). > > > > There are other convenience functions that may improve things like > > * data_exists(phoneId p, dataId d) > > It's just as quick getting the data as it is checking that it's there, so > should I implement this? OK no need then. > > > There are also two ways to minimise the amount of data Conduit must get from > > the phone in order to work out what has changed (in a phone --> something else > > sync) > > 1. Implement some sort of transaction support > > * get_changed_data(phoneId p, PhoneDataType t, magicNumber m) > > --> three lists of dataIds, added, modified and deleted > > * finish() > > --> a magic number to be used next time with get_changed_data > > 2. Implement helper functions to return data information. For example, in the > > simplest implementation, conduit will get all data from the phone, hash it to > > work out what has changed, and then transfer that to the thing synced with. > > This can be avoided by implementing something like > > * get_{mtime, hash}(phoneId p, dataId d) > > --> some string > > I'm afraid that we wouldn't be able to do any better than Conduit would there. > The amount of data would probably run in 100k, rather than megs for everything > that we can get on the phone, so Conduit is probably better off doing that at > its end. OK That sounds fine
(In reply to comment #8) > Created an attachment (id=112662) [edit] > First version of the backend API > > Depends on a patch I posted to the gnokii list yesterday, not yet committed. > > I tested the phonemgr_listener_list_all_data() and > phonemgr_listener_get_data(), delete should work, put doesn't work (I need to > unbreak some gnokii stuff first). > > Could you tell me whether the API in phonemgr-listener.h resembles something > you'd like, or does it need more error checking/errors? So far it looks fine.The choice of UID for the data and phone look good. Can you run me through what discovery looks like? AFAICT gpm emits status signals when the phone is connected, etc. Is this correct? Is there also a polled version of this, if conduit is started after gpm something like list_connected_phones() > > Note that I only implemented contacts because that's the only thing that works > with the AT driver. > OK makes sense
(In reply to comment #11) > (In reply to comment #8) > > Created an attachment (id=112662) [edit] > > First version of the backend API > > > > Depends on a patch I posted to the gnokii list yesterday, not yet committed. > > > > I tested the phonemgr_listener_list_all_data() and > > phonemgr_listener_get_data(), delete should work, put doesn't work (I need to > > unbreak some gnokii stuff first). > > > > Could you tell me whether the API in phonemgr-listener.h resembles something > > you'd like, or does it need more error checking/errors? > > So far it looks fine.The choice of UID for the data and phone look good. Can > you run me through what discovery looks like? > > AFAICT gpm emits status signals when the phone is connected, etc. Is this > correct? Is there also a polled version of this, if conduit is started after > gpm gnome-phone-manager currenly only supports one phone. So you'd just be watching for the org.gnome.phone service on D-Bus. Currently we don't have any ways to check whether a phone is connected or not (the only thing that used that service was gnome-power-manager, which would just get the number of batteries). In the future, I'll probably retool gnome-phone-manager to just an interface to a D-Bus service, which should handle multiple phones. > > Note that I only implemented contacts because that's the only thing that works > > with the AT driver. > > > > OK makes sense I'll add support for more when I can test this on a Nokia phone (Series 40 phones are the best supported ones).
I'm carrying on... I still need to implement put for calendar items, and all the functions for todo items.
Created attachment 124923 [details] [review] phonemgr-robs-changes.patch Big patch from Rob Taylor to export all that data onto the D-Bus. Will probably require some thinking as this would make the UI of gnome-phone-manager block when contacting the phone. We should probably split off the backend and UI, and have the UI just be a client to the backend exposed via D-Bus.
gnome-phone-manager is not under active development anymore since 2013. Its codebase has been archived: https://gitlab.gnome.org/Archive/phonemgr/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.