New software architecture
From Tuxisalive
Contents |
[edit] Daemon
[edit] Rough notes/ideas based on current daemon
Ok, below is a rough outline of internal communication of the daemon:
(I'm bad at image manipulation tools... and yeah, I'm very sleepy now, so didn't bother to draw with anything other than my hand)
[edit] Classes:
[edit] TCP/Message/Client
(Functionalities of existing USBDaemon_tcp_server.c)
[edit] USB
Functionalities of USBDaemon_status_table.c
[edit] System Status
Functionalities of USBDaemon_status_table.c
[edit] Device Control
Functionalities of USBDaemon_usb_readWrite.c
[edit] SOURCES
Rough work, Don't expect it to work completely :-)
Find the sources here: http://svn.tuxisalive.com/daemon/branches/CPPDaemon/
[edit] More...
[edit] Why C++
- Language, as I understand, affords less chances for code abuse
- More 'Maintainable', Less 'Coupled' code (Etc, etc... All other high-funda / super-technical stuff which most of us don't care for anyway ;-)
- Easy to add features in the long run (Long long run... You heard the StarWars theme?)
- If we are worried of unavailability of good cpp compiler which generates highly-optimized code: We don't need highly-optimized code for the daemon anyway, right? :-)
[edit] Why Not
- The current daemon is written in C and is working.
- Most of us are relatively comfortable with C (right? ;-)
[edit] Protocol
Protocol between the daemon and the manager/applications/? There's a primer of the current protocol at http://www.tuxisalive.com/Members/remi/documentation/daemon-api-protocol/
[edit] Tux Droid Manager
[edit] Why
When multiple applications are controlling tux at the same time, you'll get some conflicts. You can't have all your applications react simultaneously to the push of the head button. You're more likely to want the head button to react to a context. For example if get warned by your tux af an incoming email, you may want the head button to get the subject read but don't want that any other application reacts to the head button.
Therefore we need a manager application. This would centralize configurations and handle all applications (events and controls) instead of having applications controlling tux directly.
Let's continue the example. The manager could be configured such that when nothing happens and you press the head button, you want to hear the date and time. If the manager receives a notification from the email client, it would forward the notification to tux. If the head button is then pressed, the manager would ask the email client for the subject and all other applications wouldn't know about the head button and no time and date would be spoken.
[edit] The idea of plugins
I'm suggesting the use of plugins to interface the manager with the applications. Here are a few reasons:
- different people will have different needs and will use different applications; by loading only the necessary plugins they get the functionality they want;
- the manager is not bloated by attempting to support any application that exists; it should be possible to run it on a very small linux box by just loading the necessary plugins.
- easier for someone to write a plugin than having to understand the manager in order to add an interface to any application;
- we don't have to support all ever possible applications as someone could easily write a plugin for it;
[edit] The plugin framework
I think the plugin should simply register items in one or more lists. For example, an email plugin for evolution can add these functionalities:
- notification event
- get 'subject'
- get 'sender'
When registering the plugin, the manager would add 'evolution.email_notification' to the list of available events, and 'evolution.get_sender' and 'evolution.get_subject' to the list of available functions. Then the main configuration interface could use these events/functions to provide all the functionalities to the end user.
