Re: [Dev] A new event delivery extension on Tizen appfw

JongMyeong Ko Fri, 13 Mar 2015 02:44:30 -0700

Hi,

1), 2), 3)

This feature works based on d-bus system.

ESD is also client side of the d-bus daemon. It's not replacement of d-bus daemon.

ESD just manages the app-list for on-event-launch and serves lauching apps using app_control when the interested events ocurr.

4) At the application's launch timing, the subscription of the d-bus signals for interest events will be done.

and, if the event occurs, d-bus damon calls the library's handler and the handler calls app_control_cb of the client app.

Then, the client app could check the events using new get-type API when the app_control_cb is called.

5) For the sender validation of system-event, the d-bus security policy was applied. So, only allowed module could send system-event.

And for user -event security, there is a trusted send API which checks certification match between sender and receiver.

Best regards,
JongMyeong Ko

------- Original Message -------

Sender : Jacek Bukarewicz<[email protected]> Software Engineer/SRPOL-Security (TP)/삼성전자

Date : 2015-03-11 20:12 (GMT+09:00)

Title : Re: [Dev] A new event delivery extension on Tizen appfw

Hi,

I have a few questions:
1) Could you tell what features D-Bus daemon misses that there is a need to create a new daemon (you mentioned Event-System-Daemon in the jira ticket). D-Bus allows to send broadcasts that can be received only by interested parties. It also supports auto-activation. It will probably be easier for me to understand if you would tell how it differs from D-Bus daemon and why it's better for the use cases you described.
2) You also wrote that the implementation is based on D-Bus. Could you clarify in what way?
    - Is ESD a daemon that connects to the existing system (or session) bus?
      - Is ESD a daemon that uses D-Bus protocol but is a bus on its own - clients connect to ESD directly
3) There is a message-port daemon that allows applications to communicate with each other. It is already part of the common image. Its description says: "This daemon allows the webapplications to communicates using Tizen MessagePort WebAPI.". From quick investigation it seems that messageport is for sending unicast messages while your proposal is about broadcasting events. Still I think that possibly we could have just one messaging daemon suitable for applications?
4) How will client side work to receive events?
     - Will there be a dedicated thread that is responsible for reading events from socket?
     - Or maybe clients will be responsible for attaching to program's main loop and call some function for processing incoming data that in turn will invoke callbacks?
5) Do you already have some thoughts about the security? You wrote that application can only send user events. Is that the only security constraint? In particular do you consider privilege-based security approach (only applications having some privileges can receive certain events). My feeling is that there might be such need. This mechanism as I see it will be generic and different types of event can be broadcasted. Some of them might be sensitive.

Best regards,
Jacek

On 03/11/2015 07:10 AM, 임지웅 wrote:

Hi folks,

I'd like to propose a new event delivery extension on Tizen appfw, which is based on publish/subscribe model.
Its implementation is based on DBus and consistent interface with previous AppControl will be provided.

This extension's major features are below:
- event broadcasting between system modules and applications with two types of system-event and user-event.
- auto-activation for service type application

Here is typical use case for event subscription:

First of all, app developer should add event id and some properties in the manifest file.

<ui-application appid="org.tizen.testapp2" exec="testapp2"...>
        <eventsystem eventid=“eventsystem.tizen.system.event.battery.level_changed" on-event-launch=“false" type="system" />
        <eventsystem eventid="eventsystem.org.tizen.senderapp.user_event" on-event-launch="false" type="user" />
</ui-application>

Then, the developer could write his code like this.

static void app_control(app_control_h app_control, void *data) {
    char *eventname = NULL;
    app_control_get_event_name(app_control, &eventname);
    if (strcmp(eventname, SYS_EVENT_BATTERY_BATTERY_CHANGED) == 0) {
        _LOGD("event name is [%s]", eventname);
    }
    free(eventname);
}

Assume that service app broadcasts event like below.

void func( ) {    
    bundle *data=""
    bundle_add(data, “user_data_key1”, ”user_data_1");		
    app_control_send_user_event(“eventsystem.org.tizen.senderapp.user_event”, data);
    bundle_free(data);
}

Whenever those kind of events are published, the app could get subscribed and invoke the proper callback.

Here are all interfaces that I'm designing.
- int app_control_get_event_name(app_control_h app_control, char **event_name); 
- int app_control_get_event_data(app_control_h app_control, bundle **event_data); 
- int app_control_send_user_event(const char *event_name, bundle *event_data); 
- int app_control_send_user_event_trusted(const char *event_name, bundle *event_data); 

I created a new JIRA issue, TC2473 (https://bugs.tizen.org/jira/browse/TC-2473).

Welcome any idea to improve this proposal.

Best regards,
Jiwoong Im

_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

-- 
Jacek Bukarewicz
Samsung R&D Institute Poland
Samsung Electronics
[email protected]

_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

Re: [Dev] A new event delivery extension on Tizen appfw

Reply via email to