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_create();
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
