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 "+3XXXXX00"
string "f8294XXXXe2adf"
string "+336XXXX44"

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("[");

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.

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

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

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

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.

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 ?




--------------------------------------------------------------
Ovi Mail: Get mail on your mobile or the web
http://mail.ovi.com

Hi,

Do we have array support in dbus-scripts yet?