[Dev] Notifications in udisks-automount-agent

Zaman, Imran imran.zaman at intel.com
Fri Dec 20 15:51:47 GMT 2013


One thing that I noticed with the current notifications is that notifications stay in db even after it . 

My questions is that, who is responsible for deleting the notifications? esp. if there are more than one components that registers for the notifications from a specific entities.

Problem details
Sender sends a notification "NOT1" 
Multiple receivers (e.g. R1 and R2) are registered for such notifications which receives the notification "NOTI" and take actions..
Lets suppose R1 gets restarted, it will received "NOTI" again when it is restarted (restart can happen when the device is rebooted as well); I doubt this is the desired behaviour??..

So who and when deletes the notifications once it is delivered to all registered entities? 

From: Lynch, Rusty
Sent: 13 December 2013 18:52
To: Zaman, Imran
Cc: dev at lists.tizen.org
Subject: Re: [Dev] Notifications in udisks-automount-agent

On Fri, 2013-12-13 at 04:27 -0800, Zaman, Imran wrote:
> Hi
> Thanks for the info.
> Below is the flow that I see how notification for automount feature can work; based on which I have listed some questions if it can be answered please?
> a- There should be a setting that 'Enables/Disables' automount functionality.
> b- In case automount is disabled in settings, udisks-automount-agent sends the notifications which is eventually shown to the user. Based on the user response, agent takes the appropriate action.
> c- In case automount is enabled in settings, udisks-automount-agent automounts the device and sends the notification (which is shown to the user)..
> Q1- Does the notification solution/API (platform/core/api/notification) in Tizen is supported by both Tizen Mobile and Tizen IVI?

Yes.  All API's under platform/core/api are shared across all verticals.

> Q2- In Tizen, where (i.e. which component) can the 'utomount enable/disable' setting be placed for Tizen Mobile and Tizen IVI both OR
>        there is no such plan for any such setting and agent should automount the devices anyways?

I have no idea if the mobile UI provides a feature where user's can
enabled/disable automounting.  If it does then I would guess this
results in a vconf key getting set and then the rest of the stack
responds to that vconf setting change.

Even if the current mobile UI doesn't provide a mechanism for this, I
think defining a vconf item would be appropriate.  We have an IVI
specific settings app, and if you land code that just needs to listen
for and set some vconf key then it would be easy to update the ivi
settings app (and i would guess the same would be true for the mobile
settings app.)

> Q3- In case there will be an 'automount enable/disable' setting,
>      3a-  How would the user response be sent back to the agent?
>      3b-  Does the current Tizen notification API/solution support such functionality?

The API enables the caller to define an action for one of the buttons.
the action is pretty simple, basically just allow you to specify a
registered tizen application to launch (and I think a bundle to pass
in), but I think it should be possible to have that app really just be a
script that could do something like call a dbus method via dbus-send.

I don't know for a fact that this mechanism will work for you, but my
guess is that it would.

> Q4- Is there any wiki page for the notification solution in Tizen or source code is the only documentation :-)?

I have only learned about this by digging through all the code uploaded
by Samsung.  I don't know of any documentation since this is really a
platform API and not something being encouraged for third party app
developers to use.  There are various OSP and WRT API's that eventually
call down into this mechanism.

Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

More information about the Dev mailing list