Re: problem with dbus-scripts and Phone.SMS
On Wed, 2010-03-24 at 15:15 +0100, Nicolas Chuche wrote: But, maybe, in those cases dbus-scripts is the wrong tool and it would be better to create a custom daemon to do whatever is required. I really like the idea of dbus-scripts to handle all my dbus scripts. I don't like the idea of having many daemons waiting for dbus signal. But that could be my sysadmin past... Well if the dbus signal is frequent enough you probably _do_ want a separate daemon to offset the fork+exec overhead Now that I think of it, does dbus-scripts have some sort of rate limiting scheme so that it does not thrash the N900 on a wrong configuration ? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Ovi Mail: Get mail on your mobile or the web http://mail.ovi.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: problem with dbus-scripts and Phone.SMS
Hello,
reinventing the wheel could be hard and dangerous so I was thinking
about something like yaml. On the plus side, it's easy to parse with
libraries. On the minus side, you need to have the library on n900.
I've coded some kind of POC. It's not finished (my C is a bit
rusted...) and just print a json dump of the dbus message for the
moment.
I've only tested it on my linux workstation for the moment. You need
http://oss.metaparadigm.com/json-c/ to compile it.
If you are interested I can finish and clean it this to release it.
--- dbus-scripts.c.orig 2010-03-25 20:50:21.0 +0100
+++ dbus-scripts.c 2010-03-31 21:44:15.0 +0200
@@ -30,12 +30,15 @@
#include unistd.h
#include sys/wait.h
+#include json.h
#include glib.h
#include glib-object.h
#define DBUS_API_SUBJECT_TO_CHANGE 1
#include dbus/dbus-glib-lowlevel.h
#include dbus/dbus.h
+
+
#define DBUS_CONF_DIR /etc/dbus-scripts.d
#define DBUS_RUN_SCRIPTS
@@ -155,106 +158,135 @@
g_slist_foreach(script_list, (GFunc)script_file_call_if_matched, args);
}
-static void
+static struct json_object*
print_iter (DBusMessageIter *iter, dbus_bool_t literal, int depth)
{
+ json_object *my_object, *my_array;
+ my_array = json_object_new_array();
+
do {
int type = dbus_message_iter_get_arg_type (iter);
const char *str;
dbus_uint32_t uint32;
dbus_int32_t int32;
dbus_bool_t boolean;
-#if 0
+#if 1
double d;
unsigned char byte;
#endif
- if (type == DBUS_TYPE_INVALID) break;
+ if (type == DBUS_TYPE_INVALID) {
+ my_object = json_object_new_string(invalid);
+ break;
+ }
switch (type) {
case DBUS_TYPE_STRING:
dbus_message_iter_get_basic (iter, str);
strncpy(msgs[nmsgs], str,127);
+ my_object = json_object_new_string(str);
nmsgs++;
break;
#if 1
case DBUS_TYPE_INT32:
dbus_message_iter_get_basic (iter, int32);
sprintf (msgsv2[nmsgsv2], %d, int32);
+ my_object = json_object_new_int(int32);
nmsgsv2++;
break;
case DBUS_TYPE_UINT32:
dbus_message_iter_get_basic (iter, uint32);
sprintf (msgsv2[nmsgsv2], %u, uint32);
+ my_object = json_object_new_int(uint32);
nmsgsv2++;
break;
case DBUS_TYPE_BOOLEAN:
dbus_message_iter_get_basic (iter, boolean);
sprintf (msgsv2[nmsgsv2], %s, boolean ? true : false);
+ my_object = json_object_new_boolean(boolean);
nmsgsv2++;
break;
-
#endif
-#if 0
+#if 1
case DBUS_TYPE_DOUBLE:
dbus_message_iter_get_basic (iter, d);
- printf (double %g\n, d);
+ my_object = json_object_new_double(d);
break;
case DBUS_TYPE_BYTE:
dbus_message_iter_get_basic (iter, byte);
- printf (byte %d\n, byte);
+ my_object = json_object_new_int(byte);
break;
case DBUS_TYPE_VARIANT:
{
DBusMessageIter subiter;
-
dbus_message_iter_recurse (iter, subiter);
-
-printf (variant:);
-print_iter (subiter, literal, depth);
+my_object = print_iter (subiter, literal, depth + 1);
break;
}
case DBUS_TYPE_ARRAY:
{
int current_type;
DBusMessageIter subiter;
+json_object *local_object;
+my_object = json_object_new_array();
dbus_message_iter_recurse (iter, subiter);
-printf([);
while ((current_type = dbus_message_iter_get_arg_type (subiter)) != DBUS_TYPE_INVALID)
{
- print_iter (subiter, literal, depth);
+local_object = print_iter (subiter, literal, depth + 1);
+ json_object_array_add(my_object, local_object);
dbus_message_iter_next (subiter);
- if (dbus_message_iter_get_arg_type (subiter) != DBUS_TYPE_INVALID)
- printf (,);
}
-printf(]);
break;
}
case DBUS_TYPE_DICT_ENTRY:
{
DBusMessageIter subiter;
+json_object *key, *value;
+my_object = json_object_new_object();
dbus_message_iter_recurse (iter, subiter);
-printf({);
-print_iter (subiter, literal, depth);
+key = print_iter (subiter, literal, depth+1);
dbus_message_iter_next (subiter);
-print_iter (subiter, literal, depth);
-printf(});
+value = print_iter (subiter, literal, depth+1);
+json_object_object_add(my_object, key, value);
break;
}
+
+case DBUS_TYPE_STRUCT:
+ {
+ int current_type;
+DBusMessageIter subiter;
+my_object = json_object_new_array();
+
+dbus_message_iter_recurse (iter, subiter);
+
+while ((current_type = dbus_message_iter_get_arg_type (subiter)) != DBUS_TYPE_INVALID)
+ {
+json_object *value;
+value = print_iter (subiter, literal, depth+1);
+json_object_array_add(my_object, value);
+dbus_message_iter_next (subiter);
+ }
+break;
+ }
+
+
#endif
default:
break;
}
+ json_object_array_add(my_array, my_object);
} while (dbus_message_iter_next (iter));
+
+ return depth == 1 ? my_array
Re: problem with dbus-scripts and Phone.SMS
On Tue, 23 Mar 2010, Nicolas Chuche wrote:
Ok, found why in dbus-scripts.c. It's not yet implemented :) :
#if 0
[...]
case DBUS_TYPE_ARRAY:
{
int current_type;
DBusMessageIter subiter;
dbus_message_iter_recurse (iter, subiter);
printf([);
The original version only passed string argumnets to scripts (and used
only them for filtering). Changing that newly released version 2.0 of
dbus-scripts also uses integers and booleans. Since this change might
break older users of dbus-scripts, version 2.0 also introduced version 2
of configuration file. Only if the configuration file starts with
#DBUSV2. will use integers and booleans for filters and parameters.
I did not add arrays because I did not see the need for it, but since
you need it, there is no problem to add this. What format do you think
might be useful for passing an array of bytes as a parameter to a
script?
--
Matan.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: problem with dbus-scripts and Phone.SMS
On Wednesday 24 March 2010 11:22:34 Matan Ziv-Av wrote: I did not add arrays because I did not see the need for it, but since you need it, there is no problem to add this. What format do you think might be useful for passing an array of bytes as a parameter to a script? I tend to favour either using a filespec (a file which dbus-scripts deletes after the script has run) or using base64 (because there are probably convenient libraries in many scripting languages). Of course, this doesn't allow for more complex arrays and other complex types which dbus allows. But, maybe, in those cases dbus-scripts is the wrong tool and it would be better to create a custom daemon to do whatever is required. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: problem with dbus-scripts and Phone.SMS
I tend to favour either using a filespec (a file which dbus-scripts deletes after the script has run) or using base64 (because there are probably convenient libraries in many scripting languages). good ideas. I think I'd rather the filespec. Of course, this doesn't allow for more complex arrays and other complex types which dbus allows. reinventing the wheel could be hard and dangerous so I was thinking about something like yaml. On the plus side, it's easy to parse with libraries. On the minus side, you need to have the library on n900. But, maybe, in those cases dbus-scripts is the wrong tool and it would be better to create a custom daemon to do whatever is required. I really like the idea of dbus-scripts to handle all my dbus scripts. I don't like the idea of having many daemons waiting for dbus signal. But that could be my sysadmin past... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: problem with dbus-scripts and Phone.SMS
I did not add arrays because I did not see the need for it, but since you need it, there is no problem to add this. What format do you think might be useful for passing an array of bytes as a parameter to a script? If I'm the only one to need that no need to rush :) Perhaps a dumb yaml dump of dbus struct. http://pyyaml.org/wiki/LibYAML is quite small. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
problem with dbus-scripts and Phone.SMS
Hello, I'm playing with dbus-scripts to intercept incoming SMS. I use this rule : cat /etc/dbus-scripts.d/sms /home/user/bin/dbecho * * Phone.SMS IncomingSegment It matches but my only pass three argument to my script dbecho and not the array of bytes I wait for (the sms in pdu format) as in the dump signal following. Is it normal ? signal sender=:1.18 - dest=(null destination) serial=2129 path=/com/nokia/phone/SMS; interface=Phone.SMS; member=IncomingSegment array [ byte 4 byte 11 byte 145 byte 51 byte 102 byte 151 byte 51 byte 71 byte 244 byte 0 byte 0 byte 1 byte 48 byte 50 byte 113 byte 97 byte 131 byte 64 byte 5 byte 69 byte 58 byte 136 byte 29 byte 6 ] string +3X00 string f8294e2adf string +33644 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: problem with dbus-scripts and Phone.SMS
Ok, found why in dbus-scripts.c. It's not yet implemented :) :
#if 0
[...]
case DBUS_TYPE_ARRAY:
{
int current_type;
DBusMessageIter subiter;
dbus_message_iter_recurse (iter, subiter);
printf([);
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
