search

itm / wsn-device-drivers

Drivers for Wireless Sensor Network Devices
Other
6 stars 4 forks source link

Simplify architecture #113

Closed danbim closed 12 years ago

psotres commented 12 years ago

what exactly do you have in mind with "simplify" architecture?

I agree that it's a little bit tricky, but maybe we should focuse first in the multi-home TR support (https://github.com/itm/testbed-runtime/issues/144 and https://github.com/itm/testbed-runtime/issues/145) to be able to have an even more complete vision of the best fitting architecture for the drivers.

danbim commented 12 years ago

I found it incredibly hard to fix #110 and #113 with the current architecture as it has several design and performance flaws. The simplification is quite necessary and as the driver is the base for a lot of things I'm very reluctant to give it a lower priority than the issues you're referring to.

Speaking personally (i.e. not for my group but for me) I think I have to focus on core issues as they will also help to make the Santander requirements work in the end.

danbim commented 12 years ago

I meant #112 instead of #113

danbim commented 12 years ago

Regarding the integration of waspmotes and trisos nodes I can assure you that the changes are not very large when you know what to change. I therefore propose that I'll have a look into these branches myself as soon as I'm done with the architecture refactoring.

I think it is a good idea to merge these branches into master/develop soon whatsoever so we can have these drivers in the official release. WDYT?

psotres commented 12 years ago

I totally agree on giving priority to the driver, but as I told you I am not really sure if some considerations regarding how upper layers are going to interact with the driver should be taken prior of making any modifications to be sure that no more changes are necessary in the future. Obviously, you know how TR works much (with a lot of "muchs" following) than us, but we are somehow worried because at the end the main problem (as always happens to be) is time constraint.

Regarding the waspmote integration, I'm not sure if the status in GitHub is up to date. It's composed by 2 maven modules, one of them can be made public without problems, but the other one can't due to security reasons. Dennis have access to our private git repository if you want to have a look (or i can create an account for you if you want), but i will check and update the "generic-waspmote" module

Nevertheless, in the waspmote branch there are also some modifications on core and factories packages including the multicast support (a generic transparent multicast has been created for other devices), and some other fixes to ease the specific device development. This multicast support has to be overwritten by the multi-home devices logic if needed and right now I'm not sure how all of this will affect the drivers.