Active Topics

 



Notices


Reply
Thread Tools
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#1
Okay, firstly, I am not really sure if this belongs into the "applications" category since this is really more an extension of functionality than an application, but here it goes anyway

Background:

The default email synchronization framework for Sailfish is pretty barebones, you could say it sucks like a hoover in fact.
For IMAP accounts the only thing you can do is to set up synchronization interval, and that's it.
I have been told it is a bit better for Exchange accounts, there you can set at least busy-hour interval and off-hour interval separately.

This is way too primitive, what it means is that I'd need to suffer continuous email pings thru the night, or else manually turn it off at the end of the day.

What I want to do, is something like this, for example:
  • On weekdays I want synchronizing every 10 minutes between 06:00 and 16:00, else I want syncing every hour until midnight.
  • Between midnight and 06:00 no syncing whatsoever, I want to sleep.
  • On weekends I want to sleep late, so start syncing only after 11:00am, and sync every two hours until midnight.

Well, that does sound like job for cron, right?

Solution:
I have built and packaged the basic Vixie Cron that's been adapted to Sailfish by Zeamoceq. It's probably the simplest cron version, no extra niceties&features like on fcron but it does the job.
Now, normally I use that for backup syncing and setting up remote connections to my device, and adding email sync to crontab was no brainer.

What caused me eornomous problems was how to get cron to signal the mail client that it should do an update... I tried various ways of DBUS messaging to emulate the swipe gesture on the email UI but no avail

Thanks to @w00t, @special & @chem|st, who helped me with this!
I had gone at it from the wrong end of things, it appears that the correct way is to send DBUS message to buteo, which is the synchronization framework on Sailfish. Buteo will then trigger the sync on the email client...

This is the message to sync email:
dbus-send --session --type=method_call --print-reply --dest=com.meego.msyncd /synchronizer com.meego.msyncd.startSync string:'syncemail'

Now, my special email synchronizing schedule can be reduced to 3 lines in my crontab:
Code:
# check mail every 10 minutes during office hours on weekdays
*/10  6-16  *  *  1-5   DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/100000/dbus/user_bus_socket" /bin/dbus-send --session --type=method_call --print-reply --dest=com.meego.msyncd /synchronizer com.meego.msyncd.startSync string:'syncemail'  > /dev/null 2>&1

# check mail every hour on evenings on weekdays
1  17-23  *  *  1-5     DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/100000/dbus/user_bus_socket" /bin/dbus-send --session --type=method_call --print-reply --dest=com.meego.msyncd /synchronizer com.meego.msyncd.startSync string:'syncemail'  > /dev/null 2>&1

# check mail every second hour after I have woken up on weekends
1  11-23/2  *  *  6-7   DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/100000/dbus/user_bus_socket" /bin/dbus-send --session --type=method_call --print-reply --dest=com.meego.msyncd /synchronizer com.meego.msyncd.startSync string:'syncemail'  > /dev/null 2>&1

The installable application:
That's the crond & crontab, of course. Here is the SRPM for it

Now, why do I distribute a SRPM, wouldn't a RPM be better, huh??
Absolutely not. I have an ideological aversion to distributing binary programs, unless I really really have to. Installing unknown binary packages to your system is not something I encourage.

Hence the SRPM.

Besides, building well made SRPM's is just as easy & quick as installing a binary RPM, and it gives you the chance to peek at the source, to verify yourself that the beast really is what it claims to be.

So, for the first'timers to source package installation, this is how you do it:
rpm -i vixie-cron-3.0pl1-1.src.rpm
rpmbuild -bb rpmbuild/SPECS/vixie_cron.spec

That's it, now you have the RPM and you can install it as root:
rpm -i rpmbuild/RPMS/armv7hl/vixie-cron-3.0pl1-1.armv7hl.rpm

Now there's some dependencies you need on your device, but nothing too drastic. You need to install the following packages:
zypper in gcc rpm-build meego-rpm-config


Stability & battery usage:
I have now used this email sync method for a full week, and it works without a hitch.

I have found that this does not really increase battery consumption of the device noticeably. Most of the time cron is sleeping on a socket, waiting for a system timer wakeup event to happen.

My biggest battery eater is always the GPS track recorder I use few hours every day. If I don't use that, I have maybe 77% left after a day of maybe 18 hours active use (few phonecalls, SMS, emails, browsinf TMO, etc...)
If I use 2 hours of GPS logging in addition to that, battery could be down to 60% in the evening when I go to sleep...

You need to keep the email app open, of course, for this to work. If you close your email, synchronization event does not start it, but rather passes harmlessely.
 

The Following 11 Users Say Thank You to juiceme For This Useful Post:
Guest | Posts: n/a | Thanked: 0 times | Joined on
#2
hmm good job!

Did you try this with fcron?
(https://openrepos.net/content/nieldk/fcron)
 

The Following User Says Thank You to For This Useful Post:
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#3
Originally Posted by nieldk View Post
hmm good job!

Did you try this with fcron?
(https://openrepos.net/content/nieldk/fcron)
fcron would be needed to be patched to use DSME/iphb socket for the heartbeat. Very easy modification.

--- edit ---

Yes, really all that's needed should be something like

....
sockfd = iphb_get_fd(g_iphbdHandler);
int delta = seconds_to_wait / 4;
r = iphb_wait(g_iphbdHandler, seconds_to_wait - delta, seconds_to_wait + delta, 0);
....

or something similar to the main_loop(), and of course some bits of initialization.

Last edited by juiceme; 2014-07-08 at 20:54.
 

The Following User Says Thank You to juiceme For This Useful Post:
marxian's Avatar
Posts: 2,448 | Thanked: 9,523 times | Joined on Aug 2010 @ Wigan, UK
#4
Isn't it possible to use Buteo for the scheduling of the DBus calls, thus removing the requirement to install cron? Further still, isn't the email sync scheduling determined by a Buteo config, which can simply be edited?
__________________
'Men of high position are allowed, by a special act of grace, to accomodate their reasoning to the answer they need. Logic is only required in those of lesser rank.' - J K Galbraith

My website

GitHub
 
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#5
Originally Posted by marxian View Post
Isn't it possible to use Buteo for the scheduling of the DBus calls, thus removing the requirement to install cron? Further still, isn't the email sync scheduling determined by a Buteo config, which can simply be edited?
Could be, I did not even pursue this avenue as I have cron anyways and am used to it.

@special pointed out that the config XML's for buteo indicate that there could be more finegrained syncing possibilities than exported to the UI...
 
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#6
Update:

After the new 1.0.8.19 (Tahkalampi) SW update rolled out, it looked like my nice sync script was failing.
However, the reason was that the name of the sync profile in Buteo had changed: before it was 'syncemail' and now 'syncemail-2'

I am not really sure why this has happened, it could be related to the thing that there was some change in the accounts with that release; I have understood that now it is possible to have more than one username per account or something like that.
Or it could just be that I caused this somehow myself, having nothing to do with SFOS update....

However, the sync command that works in crontab is now this:
Code:
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/100000/dbus/user_bus_socket" /bin/dbus-send --session --type=method_call --print-reply --dest=com.meego.msyncd /synchronizer com.meego.msyncd.startSync string:'syncemail-2'  > /dev/null 2>&1
 
Community Council | Posts: 685 | Thanked: 1,235 times | Joined on Sep 2010 @ Mbabane
#7
No Jolla here, but can't IMAP-IDLE be added to the email client there? Then email will be 'virtually pushed' and no need for specifying intervals?
 

The Following User Says Thank You to sicelo For This Useful Post:
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#8
Originally Posted by qhubekela View Post
No Jolla here, but can't IMAP-IDLE be added to the email client there? Then email will be 'virtually pushed' and no need for specifying intervals?
But IMAP push is a server-side additional feature, not present on my service provider...
 
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#9
Update:

It seems the email account handling is changing in every SW update

After the new 1.1.0.38/39 (Uitukka) SW update rolled out, again my nice sync script was failing.
The reason was same as last time, the name of the sync profile in Buteo had changed again: before it was 'syncemail-2' and now 'syncemail-3'

So, the sync command that works in crontab is now this:
Code:
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/100000/dbus/user_bus_socket" /bin/dbus-send --session --type=method_call --print-reply --dest=com.meego.msyncd /synchronizer com.meego.msyncd.startSync string:'syncemail-3'  > /dev/null 2>&1
 
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#10
The same DBUS command still works on ÄijänpäivänJärvi (1.1.4.28)
 
Reply


 
Forum Jump


All times are GMT. The time now is 23:17.