Dynamic rules for oeventsd ?

Kero van Gelder kero at chello.nl
Sun Apr 12 01:26:42 CEST 2009

Hi all,

I want to let my phone ring normally, but remain silent when I'm
in a dojo or a meeting. It can ring again when someone calls me
who was supposed to be in the meeting with me. either way, some
logging of the events would be nice.

I found several things:
 (I don't think anyone implemented this? seems too static anyway)
   org.freesmartphone.oeventsd /org/freesmartphone/Events org.freesmartphone.Events.AddRule(s:rule_str)
 (this gets more dynamic, and luckily there's a RemoveRule, too)

But lacking is opimd, which seems to only provide Contacts and
Messages. I need appointments to get to the run-time knowledge
that I'm in the dojo. What's the status?

What's the available functions in rules.yaml? the docs in the file itself are
outdated. Also, the while-attribute is not explained and I see no reason
why that's not a busy-loop (while: PowerStatus() must eat 100% CPU as there's
always (Get)PowerStatus; ok, I'm being obnoxious here, it's unlikely you have
a busy-loop. But what's the difference with trigger: PowerStatus ?)

Another thing I'm wondering about is the priority and flexibility of rules.
If I'd create
 name: 'LogCallWhileInMeeting'
 trigger: IncomingCall
 action: Log('Call from XYZ at DA/TE TI:ME not answered, as you had a meeting')
 name: 'ParticipantOfMeetingCalls'
 trigger: IncomingCall
 filter: HasAttr('number', '12345678')
 action: DoAsNormalIncomingCall

I have a couple of issues:
 - mutually exclusive executions, but except for the higher specifity of
  'ParticipantOfMeetingCalls', there's nothing that prevents the
  'LogCallWhileInMeeting' rule from being executed
 - the need of filling in fields of the incoming call for the logging
 - a reference to an action 'DoAsNormalIncomingCall'
 - that reference points to a rule that is currently not even active
   (as I'm in a meeting, the rule 'NormalIncomingCall' has been removed,
   obviously; this would do the normal logging, too)

Are there solutions in place for these issues?
Should I start opening tickets?
Are these rules even the right approach for my problem, they seem to lack the flexibility that I'm looking for?
(should I subscribe to signals in my application instead, deal with the issues there?)


How can I change the world if I can't even change myself?
  -- Faithless, Salva Mea

More information about the devel mailing list