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 602642 - Separate the D-Bus Service & storage from the applet
Separate the D-Bus Service & storage from the applet
Status: RESOLVED FIXED
Product: hamster-applet
Classification: Deprecated
Component: general
unspecified
Other All
: Normal enhancement
: ---
Assigned To: hamster-applet-maint
hamster-applet-maint
Depends on:
Blocks:
 
 
Reported: 2009-11-22 15:57 UTC by Arwyn Hainsworth
Modified: 2010-04-18 18:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Arwyn Hainsworth 2009-11-22 15:57:24 UTC
Currently in order to run the D-Bus service and thus have access to the hamster storage, you must be running the applet (or standalone GUI). This is not always desirable (E.G. when using the CLI).

I suggest separating the storage and D-Bus Service from the rest of the applet.

Benefits:
* It would be easier to write ports (KDE, CLI, Shell(?))
* The service could be activated by D-Bus on request
* External plugins (Gnome-do, evolution, etc...) can access hamster DB when applet is not running or standalone window is closed.
Comment 1 Toms Bauģis 2009-12-26 12:32:55 UTC
do i understand correctly, that this would imply a hamster daemon running in background?
Comment 2 Arwyn Hainsworth 2009-12-27 14:24:33 UTC
Indeed. The daemon would be started on-demand by D-Bus and provide access to the DB via D-Bus. All front ends, including the current applet, would communicate with the daemon over D-Bus.

It actually wrote most of an implementation a month ago, but got distracted before I finished it. I was planning on finishing it over my new year break, sync it to the current master and post the patch.
Comment 3 J. Félix Ontañón 2010-03-20 11:31:08 UTC
Arwyn, what about that patch?

It could be nice interesting features, in the vein of current d-bus coding style. Maybe i can help coding?
Comment 4 Toms Bauģis 2010-03-20 12:17:50 UTC
i'll take this bug on me as the changes involved will be rather big and would be saner to be performed by the one who is maintaining the code.

some time soon after the freeze break will start looking into the subject.
Comment 5 Toms Bauģis 2010-04-16 08:07:04 UTC
Ta-tah!
This is now done. a dbus service is woken up when somebody's asking for org.gnome.Hamster, and serves all the data from hamster.storage module.

The previous hamsterdbus has been dropped to avoid any clashes and incompatibilities. 


Throughout hamster the hamster.client.Storage class is used that abstracts the dbus encoding/decoding away. This class can also be used externally, but i have not yet thought about how to track API changes. The storage backend is fairly static anyway.

Using the class is as simple as:

from hamster.client import Storage
storage = Storage()
print storage.get_facts()

I reviewed the code yesterday and added documentation, so help(hamster.client.Storage) will give you all the info.
Comment 6 J. Félix Ontañón 2010-04-17 10:16:34 UTC
It seems much clear now and works rather well. Good feature!
Comment 7 J. Félix Ontañón 2010-04-18 17:02:11 UTC
Sorry Toms,

The signals on new gobject-oriented Storage client, and so, the DBus API doesn't provides params with the changes themselves.

I mean, i.e. if i connect to client.Storage::facts-changed or storage.Storage::FactsChanged, when the event is dispatched no fact_id it's received.

I think it makes difficult for dbus-client coders, don't you think?
Comment 8 Toms Bauģis 2010-04-18 18:10:20 UTC
AddFact and UpdateFact methods both return the new fact id.
the signals are merely there to know that one has to refresh. as the hamster code is not preforming id-specific operations (as in "oh you updated fact with id 1234, which happens to be three days ago and thus i will perform slightly different refresh operation"), i imagine there is no need for that in dbus clients either.

maybe the storage.py could use some more thorough documentation. For now i just documented client.py meant for when one wants to access hamster data in python.