Maemo Alarm/Notifier Interface

I am currently looking for what developer requirements would
be from
such an Alarm/Notifier interface. Specially lot of
developers working on
applications which need to schedule events and notifications
like PIM
aplications need this functionality, and it is just not
there yet in the
Maemo Development Platform.

Some starters

1. API to
   - enable notifier/alarm events
   - cancel previously scheduled events
   - ability to specify sound file to be played for events
[I guess this
can be done by the application handling the notifier event,
so maybe not
relevant]

2. Alarm/Notifier sub system features
- ability to schedule multiple notifier alarm event
- ability to wake up device on events


Devesh


_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers

On 1/10/06, Devesh Kothari <devesh.kotharinokia.com> wrote:
> I am currently looking for what developer requirements
would be from
> such an Alarm/Notifier interface. Specially lot of
developers working on
> applications which need to schedule events and
notifications like PIM
> aplications need this functionality, and it is just not
there yet in the
> Maemo Development Platform.
>
> Some starters
>
> 1. API to
>    - enable notifier/alarm events
>    - cancel previously scheduled events
>    - ability to specify sound file to be played for
events [I guess this
> can be done by the application handling the notifier
event, so maybe not
> relevant]

I would like to have a simple-to-use approach, just like
GObject does
with the additional option to set to a given time (can be
seconds
since unix epoch, time_t or something like this). As GObject
functions
it should return the id and then you should be able to
remove by this
id.

I would like to have the system subsys to play and also
specify a
message (Rich text) to be displayed, this would eliminate
the need to
start the application just to say the alarm was due. For
user and dev
conveniece, this subsystem would get the option to postpone
events at
alarm creation time... maybe developers may specify the next
value,
something like:

add_alarm( sometime, "You need to backup",
one_day_delay, backup_callback );

That would be presented to user like:

You need to backup
[ Do it ] [Postpone to tomorrow ]


If user click the second button, alarm subsys will
reschedule the
event automatically. Many kinds of PDA apps would benefit
from this.

Also, the subsystem would need to enable 2 options of
callback: using
DBUS and executing a program (like cron does). The last
option is
needed since the user may not have the application opened or
don't
need to open it to do the action (some shell script provided
may do
the trick).



> 2. Alarm/Notifier sub system features
> - ability to schedule multiple notifier alarm event
> - ability to wake up device on events

Great.

--
Gustavo Sverzut Barbieri
--------------------------------------
Computer Engineer 2001 - UNICAMP
Mobile: +55 (19) 9165 8010
 Phone:  +1 (347) 624 6296; 08122692sip.stanaphone.com
Jabber: gsbarbierijabber.org
  ICQ#: 17249123
   MSN: barbierigmail.com
   GPG: 0xB640E1A2  wwwkeys.pgp.net
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers

Hello!

Devesh Kothari wrote:
> I am currently looking for what developer requirements
would be from
> such an Alarm/Notifier interface. Specially lot of
developers working on
> applications which need to schedule events and
notifications like PIM
> aplications need this functionality, and it is just not
there yet in the
> Maemo Development Platform.

This is a feature i really missed porting gpe-calendar. I'm
convinced that there
are some more applications which could need a feature like
this.
The most important reason to introduce a notifier interface
is that you can
easily introduce a battery drain problem with applications
doing frequent
updates/checks. That would have a negative influence on the
reputation on the
770 and maemo.

> Some starters
> 
> 1. API to
>    - enable notifier/alarm events
>    - cancel previously scheduled events
>    - ability to specify sound file to be played for
events [I guess this
> can be done by the application handling the notifier
event, so maybe not
> relevant]

I'd keep the interface as simple as possible. Call a
function to schedule an
event and get back an unique id. This is used to identify
the event in a
callback function and to cancel it. Playing sounds should be
the job of the
calling application, it usually needs to do some more action
anyway.
I can imagine that this might be useful for scheduling tasks
which are not
related with user interaction too.

> 2. Alarm/Notifier sub system features
> - ability to schedule multiple notifier alarm event
> - ability to wake up device on events

Waking up the device would be important, yes. Another
feature to think about
would be to set some command to run (and pass information
to) or a dbus service
to fire if the event time is reached. That would make it
possible to have timed
events without the need to have the calling application
running all the time.
For calendar applications this would be very useful.

I had some discussion with Kimmo about this topic some time
ago. One idea was
just to use atd. This one would need to become part of the
default filesystem
because we can't start it automatically. In addition to this
we would need to
extend it by some feature to wake up the device.
I suggested to extend the libosso time API which currently
covers system clock
changes. Making it a comprehensive interface for
time-related tasks would be an
option if it really fits into the intended purpose of
libosso.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: 0271-771091-14
and the reality of tomorrow.            Fax: 0271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boorkernelconcepts.de

6C 44 30 4C 43 20 6B 61  16 07 0F AA E6 97 70 A8
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers

On Wed, 2006-01-11 at 14:00, ext Florian Boor wrote:
> Hello!
> 
> Devesh Kothari wrote:
> > I am currently looking for what developer
requirements would be from
> > such an Alarm/Notifier interface. Specially lot of
developers working on
> > applications which need to schedule events and
notifications like PIM
> > aplications need this functionality, and it is
just not there yet in the
> > Maemo Development Platform.
> 
> This is a feature i really missed porting gpe-calendar.
I'm convinced that there
> are some more applications which could need a feature
like this.
> The most important reason to introduce a notifier
interface is that you can
> easily introduce a battery drain problem with
applications doing frequent
> updates/checks. That would have a negative influence on
the reputation on the
> 770 and maemo.
> 
> > Some starters
> > 
> > 1. API to
> >    - enable notifier/alarm events
> >    - cancel previously scheduled events
> >    - ability to specify sound file to be played
for events [I guess this
> > can be done by the application handling the
notifier event, so maybe not
> > relevant]
> 
> I'd keep the interface as simple as possible. Call a
function to schedule an
> event and get back an unique id. This is used to
identify the event in a
> callback function and to cancel it. Playing sounds
should be the job of the
> calling application, it usually needs to do some more
action anyway.
> I can imagine that this might be useful for scheduling
tasks which are not
> related with user interaction too.

Doesn't Glib has this kind of functionality already?

> 
> > 2. Alarm/Notifier sub system features
> > - ability to schedule multiple notifier alarm
event
> > - ability to wake up device on events
> 
> Waking up the device would be important, yes. Another
feature to think about

I think the system/HW takes care of wakeups automatically.

> would be to set some command to run (and pass
information to) or a dbus service
> to fire if the event time is reached. That would make
it possible to have timed
> events without the need to have the calling application
running all the time.
> For calendar applications this would be very useful.
> 
> I had some discussion with Kimmo about this topic some
time ago. One idea was
> just to use atd. This one would need to become part of
the default filesystem
> because we can't start it automatically. In addition to
this we would need to
> extend it by some feature to wake up the device.

Instead of atd, we will use cron. So, we don't have an extra
daemon in
the system. Alarms > 5min or something should use cron
and faster alarms
implemented in the application (or in a library).

> I suggested to extend the libosso time API which
currently covers system clock
> changes. Making it a comprehensive interface for
time-related tasks would be an
> option if it really fits into the intended purpose of
libosso.

Nooooo!  Isn't
Glib+cron enough?

BR; Kimmo

> 
> Greetings
> 
> Florian
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers

Hi,

HimKimmo Hämäläinen wrote:

> Doesn't Glib has this kind of functionality already?

you can have recurring events with glib, yes... but that
involves that you have
the application running all the time. In combination with
the fact that you
can't have custom software packages starting up some deamon
on boot this feature
doesn't cover all the needs. In addition to this i think it
would be much more
convenient if you just set a time of an event instead of an
interval, but thats
my personal opinion.

> I think the system/HW takes care of wakeups
automatically.

That would make this part pretty easy 

> Instead of atd, we will use cron. So, we don't have an
extra daemon in
> the system. Alarms > 5min or something should use
cron and faster alarms
> implemented in the application (or in a library).

Will there be some defined API to use this? From the
application developers
point of view you don't want to care about which mechanism
the system uses, you
just want to make it right and working. If you want to see
the correct solution
accepted by the developers its absolutely necessary to
provide a useful API.

Do we have any experience on how cron influences power
consumption? From what i
see on my 770 we don't have it running in the current
software image.

> Nooooo!  Isn't
Glib+cron enough?

It depends on two questions:
- Does it work?
- How do you expose this to the application developers?

Well... i know that i'm complicated 

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: 0271-771091-14
and the reality of tomorrow.            Fax: 0271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boorkernelconcepts.de

6C 44 30 4C 43 20 6B 61  16 07 0F AA E6 97 70 A8
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers

Hi,

On Wed, 2006-01-11 at 17:12, ext Florian Boor wrote:
> Hi,
> 
> HimKimmo Hämäläinen wrote:
> 
> > Doesn't Glib has this kind of functionality
already?
> 
> you can have recurring events with glib, yes... but
that involves that you have
> the application running all the time. In combination
with the fact that you
> can't have custom software packages starting up some
deamon on boot this feature
> doesn't cover all the needs. In addition to this i
think it would be much more

Looking at crontab(5) man page, cron allows you to execute a
program
once in startup, so you could start some kind of daemon like
that.

> convenient if you just set a time of an event instead
of an interval, but thats
> my personal opinion.

You could have a shell script launched by cron that checks
the current
time of day and, if the time is right, starts some program
that plays
annoying alarm sound at full volume.

> 
> > I think the system/HW takes care of wakeups
automatically.
> 
> That would make this part pretty easy 
> 
> > Instead of atd, we will use cron. So, we don't
have an extra daemon in
> > the system. Alarms > 5min or something should
use cron and faster alarms
> > implemented in the application (or in a library).
> 
> Will there be some defined API to use this? From the
application developers
> point of view you don't want to care about which
mechanism the system uses, you
> just want to make it right and working. If you want to
see the correct solution
> accepted by the developers its absolutely necessary to
provide a useful API.

I guess the 'API' is crontab(1) + crontab(5). It has
probably been
tested in the course of time and proven good and stable.

> Do we have any experience on how cron influences power
consumption? From what i
> see on my 770 we don't have it running in the current
software image.

I assume it will sleep most of the time and poll once in a
minute
(according to man page).

> > Nooooo!  Isn't
Glib+cron enough?
> 
> It depends on two questions:
> - Does it work?
> - How do you expose this to the application developers?

I think the application developer will use the crontab(1)
command and
the Glib API.

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.

BR, Kimmo

> 
> Well... i know that i'm complicated 
> 
> Greetings
> 
> Florian
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers

On 11/01/06, Kimmo Hämäläinen <kimmo.hamalainennokia.com> wrote:
>
> I assume it will sleep most of the time and poll once
in a minute
> (according to man page).

Polling once a minute is much too often, though! The daemon
(even if
it's crond) should get told, possibly over DBUS, when a
scheduled
event is added. It then recalculates its sleep time, and
goes back to
sleep until the next currently known event is due.

Looking at the source to atd(8), this is what it seems to
do.

Cheers,

Andrew

--
Andrew Flegg -- mailto:andrewbleb.org  |  http://www.bleb.org/
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers

Kimmo Hämäläinen (kimmo.hamalainennokia.com) wrote:
> I guess the 'API' is crontab(1) + crontab(5). It has
probably been
> tested in the course of time and proven good and
stable.

Uh, not if you have potentially multiple programs
simultaneously
modifying the crontab. One faulty program could mess up your
whole cron
environment and you don't really want that.

> I think the application developer will use the
crontab(1) command and
> the Glib API.

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.

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.

> 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'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.

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

_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Flegg schrieb:
> On 11/01/06, Kimmo Hämäläinen <kimmo.hamalainennokia.com> wrote:
> 
>>I assume it will sleep most of the time and poll
once in a minute
>>(according to man page).
> 
> Polling once a minute is much too often, though! The
daemon (even if
> it's crond) should get told, possibly over DBUS, when a
scheduled
> event is added. It then recalculates its sleep time,
and goes back to
> sleep until the next currently known event is due.
> 
> Looking at the source to atd(8), this is what it seems
to do.

In the hh.org atd for iPaq and friends we even make use of
the RTC of
the StrongARM. This will be set to the next alarm and will
cause an
interrupt when the event occurs.
This has two major advantages:
1. You do not have to poll and you do not have to trust that
sleeping a
certain amount of time is accurate enough with the real
time.
2. The RTC interrupt will wake up the machine when it is
suspended thus
you get notified about events even if in suspend mode. I
would suspect
that the OMAP has a similar RTC which is capable of
generating a wakeup
interrupt.

In this case I would vote for atd again because the hh.org
atd already
carries the necessary mods to make use of the RTC.

> Cheers,
> Andrew
Cheers
  nils faerber

- --
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


iD8DBQFDxTfsJXeIURG1qHgRAm/9AKCnOvqzCuM9rGU06nRDZ3t49AaGNQCg
i0cC
xj9cZ+mZoJ0MsRPJlPl+lPQ=
=/6HO
-----END PGP SIGNATURE-----
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers

Hi,

Kimmo Hämäläinen wrote:

> Looking at crontab(5) man page, cron allows you to
execute a program
> once in startup, so you could start some kind of daemon
like that.

that might be an option... as soon as we have cron which is
currently not available.

> You could have a shell script launched by cron that
checks the current
> time of day and, if the time is right, starts some
program that plays
> annoying alarm sound at full volume.

Thats a hack, not a feature and leads exactly to the
situation we want to avoid.

> I guess the 'API' is crontab(1) + crontab(5). It has
probably been
> tested in the course of time and proven good and
stable.

... for a completey different usecase: We are not talking
about software for a PC.

> I assume it will sleep most of the time and poll once
in a minute
> (according to man page).

I suppose thats too frequent to avoid power drain, iirc we
had a problem like
this with the panel clock. Apart from this i think the
resolution of one minute
is too low...

> I think the application developer will use the
crontab(1) command and
> the Glib API.

I don't think the crontab command is an acceptable interface
for GUI
applications, we would need a library offering a proper API.

> 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 think we are talking about two different things - the
implementation of a
service and a service API.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: 0271-771091-14
and the reality of tomorrow.            Fax: 0271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boorkernelconcepts.de

6C 44 30 4C 43 20 6B 61  16 07 0F AA E6 97 70 A8
_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers