After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 456259 - Add get/set for PIM through D-Bus
Add get/set for PIM through D-Bus
Status: RESOLVED WONTFIX
Product: gnome-phone-manager
Classification: Other
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: none
none
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2007-07-12 14:36 UTC by Bastien Nocera
Modified: 2018-08-17 18:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
First version of the backend API (9.90 KB, patch)
2008-06-13 07:52 UTC, Bastien Nocera
none Details | Review
Updated patch (14.36 KB, patch)
2008-06-16 16:53 UTC, Bastien Nocera
none Details | Review
phonemgr-robs-changes.patch (26.35 KB, patch)
2008-12-18 13:38 UTC, Bastien Nocera
none Details | Review

Description Bastien Nocera 2007-07-12 14:36:00 UTC
For Conduit to use.

It should allow to get/set:
- Contacts
- Calendar items (appointments)
- Todo items
- Notes
Comment 1 John Stowers 2008-02-05 04:22:31 UTC
Any movement or direction on this? 

Now that conduit has a glib binding library, controlling it from C apps should be a breeze.
Comment 2 Bastien Nocera 2008-03-08 02:09:26 UTC
(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.
Comment 3 John Stowers 2008-03-11 02:34:22 UTC
(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.



Comment 4 John Stowers 2008-03-11 02:37:54 UTC
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
Comment 5 John Stowers 2008-03-11 02:41:10 UTC
(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.
Comment 6 Bastien Nocera 2008-06-12 15:11:35 UTC
(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.
Comment 7 Bastien Nocera 2008-06-13 05:33:43 UTC
(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.
Comment 8 Bastien Nocera 2008-06-13 07:52:49 UTC
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.
Comment 9 Bastien Nocera 2008-06-16 16:53:49 UTC
Created attachment 112850 [details] [review]
Updated patch

This should fix the _put() function. _list_all_data() needs more work.
Comment 10 John Stowers 2008-06-16 22:33:45 UTC
> > 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
Comment 11 John Stowers 2008-06-16 22:42:39 UTC
(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
Comment 12 Bastien Nocera 2008-06-17 16:47:58 UTC
(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).
Comment 13 Bastien Nocera 2008-06-20 13:06:49 UTC
I'm carrying on... I still need to implement put for calendar items, and all the functions for todo items.
Comment 14 Bastien Nocera 2008-12-18 13:38:53 UTC
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.
Comment 15 André Klapper 2018-08-17 18:48:52 UTC
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.