Open Device Daemon, Progress Resport 3 [GSoC]

[Sudharshan S]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael 'Mickey' Lauer wrote:
> 
> 1) dbus API. Please synchronize your API with a) the Dbus naming scheme, e.g. 
> see our (brief) style guide from OTAPI:
> 
>> Style Guide:
>> * dbus methods and signals are CamelCased
>> * Use Get/Set prefixes for accessors (GetServiceCenter, SetServiceCenter)
>> * Use Verbs for operations (ListProviders, Unlock, SendAuthCode)
>> * Use similar terms for similar operations (ListProviders, ListCells)
> 

Okie Dokie, Done. Currently, vala doesn't allow to follow the camelcase
convention for signals :(.

(I just need to push it to the git repos. Getting a "Remote host hung up
unexpectedly" while I git push. git push works for other repos though :(  )

> b) Please synchronize the API with python-odeviced. It is planned for odeviced 
> to be a drop-in replacement for python-odeviced, hence the API should be 99% 
> compatible. If you have critique points, lets discuss them individually here.
> 

Will do.

> 2) plugins. Here I'd also like you to change two things. a) the granularity of 
> your plugins, i.e. just as in python-odeviced, I'd like to see a kernel 2.6 
> plugin that handles linux 2.6 device classes (backlight, RTC, leds, power 
> supplies).
> 
> b) It is important that the plugins autoadd/configure individual dbus objects 
> as much as possible, i.e. the generic kernel 2.6 plugin should scan sysfs for 
> all class devices it cares about (backlight, RTC, leds, power) and create one 
> object for every class device.
> 

Regarding the kernel26 plugin, why not add a helper function instead
that'd compute the sysfs node and subsequently create object paths
dynamically? Something like this,

ODeviced.compute_dbus_objects(string devclass)

devclass being one of the device classes. Since devclass is something
that is the same in all the devices (I hope). We could set this in the
configuration of the respective plugin. After reading this from the conf
file, the plugin_init function could then call the forementioned helper
 routine to compute DBus object paths dynamically. One per every
directory (or link) under each device class.

In practise, in my laptop
/org/freesmartphone/Device/PowerSupply/ACAD, ..BAT1 object paths would
be created, just as python-odeviced does.

This solves the current way of hardcoding nodes for each device and at
the same time achieving what kernel26.py does.

What are your thoughts on this?

I hope I conveyed the right intent, Please tell me if I am unclear
somewhere.

Apart from the fact that all interfaces within kernel26.py uses sysfs
device classes, did I miss another crucial reason to group them under a
single plugin.

Regards and Thanks,
Sudharshan S
Blog : http://www.sudharsh.wordpress.com
IRC  : Sup3rkiddo @ freenode, gimpnet
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhOykQACgkQSsRjJNRMc4kLhwCgiLg92YfEZGIW4o67dpvlyhjh
Lf8AoK/FAFzpVrQQjvaqZWWsmCUOcsd8
=AvD4
-----END PGP SIGNATURE-----