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 545816 - Synchronization to/from google calendar or other resources
Synchronization to/from google calendar or other resources
Status: RESOLVED WONTFIX
Product: hamster-applet
Classification: Deprecated
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: hamster-applet-maint
hamster-applet-maint
: 535816 538139 572362 572871 572914 580709 618713 628512 629178 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-08-01 09:05 UTC by David Danier
Modified: 2012-09-24 18:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch adding ability to use multiple storage methods, including paymo client (90.39 KB, patch)
2008-08-03 11:36 UTC, David Danier
none Details | Review
Google Calendar as Hamster Storage (13.71 KB, patch)
2008-11-25 15:57 UTC, k0sh
none Details | Review
Conduit sync module using Hamster DBus methods (7.45 KB, text/plain)
2009-11-06 16:03 UTC, hne
  Details

Description David Danier 2008-08-01 09:05:04 UTC
Like mentioned in #535816 I think making the storage-system somwhat more flexible could improve the things Hamster could handle. Currently I think there shouldn't be much work to get this done, as storage seems pretty modular (great work!). Only things seems to get a modular import using __import__ (instead of only beeing able to use hamster.db), the storagy itself is defined in storage.py anyway. In the future we could improve the storage-API (for example using objects to represent categories, ...), but thats not really needed to provide simple support for different storage engines.

The things that need to be changed:
 * Use dynamic import, based on some settings
 * Create a GUI for storage-selection
 * Support configuration of storage-engine
Comment 1 David Danier 2008-08-03 07:54:52 UTC
I have a simple test running, not sure how to do the select-box and configuration-stuff for external storage methods and storing data ist currently not cached (for performance). But Hamster is running using paymo (http://www.paymo.biz/) here. Settings are read from static python, file but it seems working. Of course not all things the GUI provides are possible with paymo (for example changing the order of tasks), so the storage-methods are stubs here, but the core functionality is there. Funny thing: Hamster actually provides more features than the official client.

I will add a patch, once I figured some of the configuration stuff. :)
Comment 2 David Danier 2008-08-03 11:36:41 UTC
Created attachment 115775 [details] [review]
Patch adding ability to use multiple storage methods, including paymo client

This patch changed many things and may have fixed some problems I had:
 * storage-classes are now organized under hamster.storage_methods
 * hamster.storage now no longer collapses with module (hamster has a variable names storage, too)
 * storage method can be selected in preferences
 * storage methods may define it's own settings dialog
 * paymo storage methods included (hamster/storage_methods/paymo.py and data/paymo-configuration.glade)
   - this needs work
   - requests should be cached, so GUI does not get blocked
   - configuration looks ugly
   - no way to save data when offline (see caching above)
   - uses pymo-module I'm writing on, which is not released yet
     paymo said official API specifications will be available soon, so I'm waiting for this to happen...current module uses API of web-client (wireshark rocks)
   - not all things Hamster does is supported by paymo (example: change order of things), so this does not work
 * hamster.__init_db() renamed to _init_db, this caused problems when trying to import in classes (Python thinks __ means private and renames the import)
 * hamster._change_db() to change storage method, triggers configuration-dialog if needed
 * hamster.get_db() to use storage, no direkt importing hamster.storage any more
 * support modules with saving configuration data
 * new storage-methods:
   - activate(): storage method is used, here code should go that currently may be in __init__()
   - deactivate(): code that is needed on shutdown/storage method change (example: disconnect/logout)
   - needs_configuration()/has_configuration()/configuration(): methods to control configuration of storage method
   - STORAGE_NAME/STORAGE_ID: Variable to identify storage method

There are some things I think are not ideal though:
 * You need to simulate sqlite-return values, classes would be nice here to wrap all internal date
 * There is no was in current storage to update facts, remove and readd does the same, but update would be nicer in other storage methods
 * get_db() everywhere isn't this great, perhaps another mechanism may be found here
 * storage method autodiscover is missing, currently there is duplicated data
 * some more things I forgot ;-)

Please comment the code, so I can push this further. ;-)
Comment 3 David Danier 2008-08-03 11:55:38 UTC
Some screenshots:
http://users.webmasterpro.de/~ddanier/hamster/
Comment 4 Patryk Zawadzki 2008-08-06 06:31:48 UTC
I think we can leave the storage as-is and instead add Conduit support to sync the local storage with some online services (like Paymo or Google Calendar). Would that work?
Comment 5 Anirudh Sanjeev 2008-08-09 14:25:37 UTC
Hi,

I'm trying to implement a commandline client to hamster. I've read through some of the code and have a standalone version running. However the traces are quite large, and I was wondering if there was a single class that you use to handle storage and addition to the hamster database?

I have isolated two options for me now:

1. mock up an object with sufficient members that can be used in daystore

2. Use the storage module to manually add facts, categories, etc.

I can work with either but modifications on your side shoudln't break my build.

Thanks
Comment 6 David Danier 2008-08-10 08:28:24 UTC
(In reply to comment #4)
> I think we can leave the storage as-is and instead add Conduit support to sync
> the local storage with some online services (like Paymo or Google Calendar).
> Would that work?

Not sure...

Currently my patch only tries to use the existing methods to implement a different storage engine. But on my way there I found some things that Hamster does, which third-party-storage might not support. One example might be the feature to add new tasks in the select-box (in menu.glade). It might be possible to add these when syncing, but chossing some fallback-category might lead to problems (for example you can't move a task to another category in Paymo).

Additionally Hamster uses the task-name when selecting the current task. This may give you huge problems, with the same tasks inside different categories. I dont' think this is so uncommon, just think about categories for your clients, which all may have some deployment/testing/... task.

So I think even with syncing: Some work inside Hamster might be needed. Personally I would suggest starting with creating some classes to wrap the internal items (categories, tasks, ...). This might even be usefull for syncing, as you need some sane way to read and save data. Seems like Anirudh (comment #5) suggests this, too...for a commandline client.
Comment 7 k0sh 2008-11-25 15:57:03 UTC
Created attachment 123368 [details] [review]
Google Calendar as Hamster Storage

Hi, I'm from Russia. Sorry for my English, I use Google Translate. I added in Hamster ability to use Google Calendar as storage. It's not 100% worked version. After patching, You must edit hamster/gcal.py to enter your Google Acount information.
Comment 8 Toms Bauģis 2008-11-25 16:21:58 UTC
*** Bug 538139 has been marked as a duplicate of this bug. ***
Comment 9 Toms Bauģis 2008-11-25 16:24:37 UTC
Looks like a good start, k0sh!
Still, to reduce latency (and also to be able function off-line), it would make more sense to do synchronization, instead of replacing all functions. 
It would also be more easier to maintain code that way.

Could you transform your patch into that?


Changing bug summary to mark that we would like to go sync way instead of replacing.
Comment 10 k0sh 2008-11-26 05:59:59 UTC
Thanks Toms! I try it.
Comment 11 John Carr 2008-11-29 15:34:42 UTC
If anyone is interested in the syncing route via Conduit i'm happy to help. We can either expose your database over dbus and let Conduit auto-sync it, or if you prefer we can probably arrange an "import conduit". From where I am, the dbus route is preferred, really...

(I'm interested in this for syncing hamster to my other laptop and for perhaps providing times to my boss.
Comment 12 Toms Bauģis 2008-12-01 13:25:12 UTC
Go for it, John! 
Err, for the dbus approach that is!
Comment 13 Maciej Katafiasz 2009-01-24 10:55:44 UTC
FWIW, the conduit method is problematic for what I wanted to use hamster for. At our company, we're currently tracking time by adding new "hours" items to tasks defined in the internal CMS. The system works, but is rather crude, so the company wants to move to a more hands-free approach (ie. something like hamster). I wanted to add the stuff we need to hamster, as I use it personally already, but for that, the conduit route is no-go. 

First, I'm the only one using Linux here, everyone else is on windows. There's hamster port for windows (which I'm fighting with currently), but I couldn't use conduit there. Second, I'm not sure conduit could sync the data between hamster.db and our CMS, although it might be possible, it seems to support data conversion. Still, there are things like auto-populating task-list from the tasks currently defined in the CMS that I don't quite see being doable if we offload the syncing to conduit.
Comment 14 Toms Bauģis 2009-02-19 09:42:07 UTC
Maciej - since i don't use your CMS, i can't be sure either, but if you are thinking about any kind of sync, one-sided in this-case, i think, a customized version of a potential hamster conduit module would be most appropriate.

see http://www.conduit-project.org/wiki/CodeOverview

John - i wonder if you could help with what is needed to be able to sync via DBUS?
Comment 15 Toms Bauģis 2009-02-19 09:42:11 UTC
*** Bug 572362 has been marked as a duplicate of this bug. ***
Comment 16 Toms Bauģis 2009-02-23 16:49:09 UTC
*** Bug 572871 has been marked as a duplicate of this bug. ***
Comment 17 Toms Bauģis 2009-02-23 23:43:42 UTC
*** Bug 572914 has been marked as a duplicate of this bug. ***
Comment 18 Toms Bauģis 2009-04-29 08:46:40 UTC
*** Bug 580709 has been marked as a duplicate of this bug. ***
Comment 19 hne 2009-11-06 16:03:02 UTC
Created attachment 147108 [details]
Conduit sync module using Hamster DBus methods

This is a first version only supporting Hamster as source of Calendar Events.
I've tried it in the newest Conduit from git, but only against an Evolution Calendar. It seems a little bit buggy, but should be a starting point for someone with a bit of tinker in their fingers.
Comment 20 Toms Bauģis 2010-02-08 17:44:48 UTC
*** Bug 535816 has been marked as a duplicate of this bug. ***
Comment 21 Eduardo Grajeda 2010-03-23 16:26:16 UTC
I think it would be more convenient if you could choose the service to sync-to within the preferences window (http://imgur.com/tEZ7J.png or http://imgur.com/NVPIS.png) rather than going all the way to conduit for that.
Comment 22 Toms Bauģis 2010-03-23 17:02:43 UTC
you are right - adding a list item to preferences certainly solves all the problems!
Comment 23 Toms Bauģis 2010-05-15 15:26:15 UTC
*** Bug 618713 has been marked as a duplicate of this bug. ***
Comment 24 Toms Bauģis 2010-09-01 15:19:09 UTC
*** Bug 628512 has been marked as a duplicate of this bug. ***
Comment 25 Toms Bauģis 2010-09-09 17:09:29 UTC
*** Bug 629178 has been marked as a duplicate of this bug. ***
Comment 26 Toms Bauģis 2012-09-24 18:22:06 UTC
the ticket was bit vague and no progress was done.
feel free to reopen the bug in github with a specific backend in mind:
https://github.com/projecthamster/hamster/issues?state=open