Talk:New software architecture

From Tuxisalive

Jump to: navigation, search

Recently I faced the same problem but as I hadn't seen this wiki page, I thought about another solution.

Contents

[edit] About the "plugins"

  • Tux software keep being standalones. This way, they can be triggered by cron, or any other action.
  • They connect directly to the daemon, using the API.
  • They must follow certain rules:
    • At start, they must backup the current Tux status (eg motors positions & leds status).
    • When they need to make Tux move/talk/wait for user action, they must get and then release shared mutexes. This is to avoid 2 client applications to send (repectively wait for) orders simultaneously. There would be 3 mutexes : motor control, speech, user events.
    • On exit, they must restore the initial state fo the droid, excepted specific cases (example: if an application checks your mailbox and you have unread mail, it will put the wings in 'up' position to notify you. You can then aknowledge the information by clicking on the head).

Now, as most of these applications are triggered on demand and only last less than one minute, I need a permanent client to "manage" them and listen to user events.

[edit] The client manager

Its tasks are:

  • To disable tux at night (using the light sensor and the computer's clock). It can use the sleep mode if available.
  • To store, and be able to read again the messages played by the other clients. Example: the "email" software told me I got 3 new emails but I was not around. Then, I notice my Tux has its wings raised, which means I missed an event. Using the remote controller, I can play again the last messages (they need to be stored somewhere: text file, database, ...).
  • To provide other functions available at anytime (such as controlling audacious using the remote ctrl).
  • To check mutexes are released after a certain duration (watchdog).

[edit] Conclusion

[edit] PROS

  • No need to make changes in low-level code
  • No need to manage timers, to launch tasks periodically (plugins system)

[edit] CONS

  • The applications need to follow the rules or it will soon be the chaos !
  • An instance of Python must run 24/7 for the client manager. On embedded devices, this require memory.
  • Only one application can wait for user events at a time.


That may not be the best solution, but at least it's another point of view. Feel free to give your opinion !

Retrieved from "http://wiki.tuxisalive.com/index.php/Talk:New_software_architecture"
Personal tools