[GSoc]: Open Device Daemon, odeviced: Progress Report 5

[Sudharshan S]

Hi all,

The last few days has been wonderfully exciting for me, since I got to
play with the Freerunner (*evil grin*). Here are the changes since the
last progress report.

1.) Catch up with python-odeviced with regards to naming conventions
2.) Test odeviced with zhone. Battery meter works
3.) Re-introduce DBus interface for the service. Add a new
ListObjectsByInterface method, which returns an array of strings
containing the DBus objects for that interface
4.) New rtc plugin (RealTimeClock)
5.) Bitbake recipe to build odeviced for OE-supported devices. This
requires vala-svn which is not in OE atm.

What's next
-----------
1.) Input plugin. This is a trickier part since I will be reading from
the /dev/input/event*. I guess, event2 and event3 are event nodes for
the accelerometers. Initially I thought of creating a separate plugin
for the accelerometers, which would spawn DBus signals with the relevant
data as the payload. hexdump shows that a constant stream of data is
generated in these device nodes, which I feel would make way for some
latency. What are your thoughts on this?

2.) FSO now has a generic framework daemon which encapsulates all the
daemons, ousaged, ophoned..etc, as subsystems. This removes the need for
multiple instances of the python interpreter. So can I go ahead and
create a similar structure?, if this final, then creating
C-implementations in the future can be pretty easy.

But I have a question on this. Since, the daemon is a single infinite
loop, it would rather get sloppy if, for some reason, we get stuck in a
particular task. Threading is an obvious solution, but I am not really
keen on threading as it would get scary later on. Moreover, GSM modems
are slow, so this becomes a matter of concern. I had a chat with my
mentor, mickeyl on this.


Regards
Sudharshan S
Blog : http://www.sudharsh.wordpress.com
IRC  : Sup3rkiddo @ Freenode, Gimpnet