[maemo-developers] [maemo-developers] Maemo Alarm/Notifier Interface

[From: Simon Budig]

Kimmo Hämäläinen (kimmo.hamalainen at nokia.com) wrote:
> We have also other places where multiple simultaneous programs would
> screw things. Usually this can be avoided by the fact that the user can
> only use one application at a time.

Oh right. "Our System is broken anyway, so lets add more broken stuff."

Sorry, this is *not* good software engineering.

> On Wed, 2006-01-11 at 18:50, ext Simon Budig wrote:
> > The crontab(1) command cannot add an entry to the crontab, all it can do
> > is pop up $EDITOR for the user to edit the crontab. Not what you want.
> 
> My man page (old debian/testing) says that it can: "The first form of
> this command is used to install a new crontab from some named file or
> standard input..."

Right, I missed that. It doesn't really help, since it installs - as far
as I understand the manpage - a *new* crontab, discarding old entries.

> > Glib also is not always a good idea: It can handle timeouts but does not
> > make any guarantees about them. Plus - as florian already mentioned - it
> > would require your program to run all the time and waste memory.
> 
> I think the user does not except atom clock precision anyway. Cron would
> allow the application to be launched closer to the set alarm, so the
> running time of the application could be minimised.

Well, OTOH I don't think that differences >= 1s are acceptable. If we
launch an application to just play the sound we very well are in this
range of prescision.
 
> > > We will try to re-use existing (preferably standard) software, so unless
> > > cron is not enough, it will be preferred over some new daemon
> > > implemented from scratch.
> > 
> > I'd love to have an API call that enqueues an alarm at a specific time
> > (maybe even with a specific sound, but I doubt that it should provide
> > any dialog facilities, that would make it quite complex) that calls back
> > into the application via dbus. That would make it possible to disable
> > alarms globally (similiar to the flight mode - a "cinema mode"  :) and
> > would enable a list of scheduled alarms, regardless of the application
> > that scheduled it.
> 
> You can use DBus from a crontab if you want (e.g. with dbus-send). Also,
> stopping and restarting cron is possible.

The question IMHO is not what I *can* but what I *want*. Of course I can
implement applications write()ing the X-protocol to a socket of the
system, that hopefully results in a window presented by the X-Server,
but that does not mean that it is clever or feasible. Libraries exist
for a reason.
 
> > You'd have to hack a lot around crontab to enable all this and I doubt
> > that would be significantly less error prone than implementing that
> > stuff e.g. in the Desktop application or a new demon specific to that
> > task.
> 
> What was so difficult with cron?

Ok, let me try some pseudo code to add an crontab entry for an alarm
from within an application written in C.

   minutestring = g_strdup_printf ("%d", minute);
   hourstring = g_strdup_printf ("%d", hour);

   addcommand = g_strdup_printf ("(crontab -l ; echo \"%s %s %s %s %s   %s\")"
                                 "| crontab -",
		                 minutestring,
		                 hourstring,
		                 "*", "*", "*",
                                 commandstring);
   
   system (addcommand);

   g_free (addcommand);
   g_free (minutestring);
   g_free (hourstring);

Removing an entry from the crontab would require more advanced trickery
with sed to remove the entry from the crontab -l listing. Beware to not
remove an entry by another application! And make sure to get the quoting
for your shell commands exactly right. How do you quote spaces in an
argument to dbus-send when invoking the above command?

Of course some of this complexity could be hidden by custom shell
scripts. You'll always have the quoting issues though. Getting a list of
the currently scheduled alarms needs another mechanism, according to
your approach it would probably mean implementing a parser to get the
information from the output of a shell script.

Now. Someone not too familiar with shell programming wants to use this
and it does not work. What do you tell him?


Now compare this to this:

  osso_time_schedule_alarm (context,
                            alarm_time,
			    OSSO_ANNOYING_SOUND,
			    my_custom_callback_function);

(or whatever, I did not think very deeply about the arguments).

It would be typesafe, incredibly easy to use and if it doesn't work the
blame is on Maemo. Great for application developers  :)

I hope that helps you understanding the importance of a proper API.

Bye,
        Simon
-- 
              simon at budig.de              http://simon.budig.de/