On Wed, 2006-01-11 at 20:20, ext Simon Budig wrote:
> Kimmo Hämäläinen ([EMAIL PROTECTED]) 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.
In general, no; but sometimes it's good to think before overengineering
stuff...
> > 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.
We can avoid this with some nice wrapper. Note that we can use separate,
named crontabs for each alarm.
> > > 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);
We can avoid this with some wrapper, I think.
> 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 think we'll just have a wrapper for crontabs. The function above looks
like functionality that is available from Glib. Implementing this kind
of generic function would be too risky, because of the complexity
involved when taking e.g. background killing and power cuts etc. into
account.
If this already exists (in GPE?), OK let's use it. If not, let's play
safe.
BR; Kimmo
>
> I hope that helps you understanding the importance of a proper API.
>
> Bye,
> Simon
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
