ContextLogger2 Roadmap

• Should consider using the "Internet" logical access point in newer Symbian devices as a sensible default (when available). The Qt API at least now reports it on Symbian Anna.
• It would be good to have a descriptive error dialog should there be an error parsing/evaluating the contents of any configuration file.
• Create/find Lua bindings for sqlite3 database access. Adapt for log database (LogDb) access; this will allow for database queries via the Symbian client/server interface, and later remotely. See libluasqlite3.c in the codebase. We can remove database opening/closing functions, and just export a handle to the one database that we do have.
• An end-user logger control panel application. Something simple and pretty, just for starting and stopping logger and watchdog. Based on Qt, probably. On recent devices this could possible be a widget to put on the home screen.
• For installation convenience, should find out if required SSL certs are installed, and if not, automatically install them or (if that is not possible) launch an interactive installer to do it. Could similarly install Watchdog, even though its SIS cannot be embedded; the SIS could probably be unpacked from the mega-SIS, then programmatically installed, and then programmatically launched. There is a mctwritablecertstore.h header at least in some SDKs, which has functionality for adding certs. The mcertstore.h supports listing of certificates. There also is an API for doing programmatic software installation (see pyswinst, say). This functionality could be coupled with the user-friendly control panel application, to help keep things running, and to show what is running.
• WLAN scanning would be a useful addition for collecting location data. Look at the wlantools Python extension, or at WLANMgmt. Alternatively: it seems that Symbian^3 devices support 'Wi-Fi/Network' positioning, and we might be able to just use an RPositioner to get position information based on WLAN information, say in the cellpos sensor, after cell ID changes.
• Implement a cross-platform sensor based on each of the following Qt Mobility Sensors API sensors: QAccelerometerSensor, QCompassSensor, QOrientationSensor, and QRotationSensor. See also Symbian Sensor Channel API for info on the underlying sensor interface. Note that the polling Qt-based sensors are IPC heavy as revealed by sensorbackendsym.cpp, which requests readings without any buffering. Specifying a dataRate may be important.
• Grab an SMS sending function (some new Nokia libs out there make this really easy). Create a Lua binding. Also define an sqlite function for evaling a Lua expression. This makes it possible to remotely set up database triggers that send notifications via SMS. May want to restrict numbers for security, no premium numbers please; specify a number validator in Ragel.
• A status indicator that shows whether the logger is running, on the standby screen. ContextPhone has this, and we can perhaps use the same code; see ContextNotify (server drawing on top of Phone screen) and ContextNotifyClient (driving the thing); this solution is a klugde, though, but the only thing that one can do pre-N97 without being a manufacturer.
• A proper status indicator for devices with N97 style standby screen. On the N97 (only) there is the Home Screen Publishing API that we can use instead of more kludgey solutions. Symbian Anna certainly should have decent support for this.
• Could use some Lua bindings for Remokon access. Start, stop, is running, is connected, is enabled, send given message to given JID, etc. Add Remokon submenu to Launcher.
• Could use a command for resetting Lua state in remote control sessions, to prevent running out of memory in cases where say a lot of variables are assigned to in the "REPL". This may be the one thing that perhaps should not be done in Lua itself, as it might be hard to do it safely.
• Authenticate uploaders. Presently, there is server authentication and confidentiality for uploads, but no client authentication. Hence unauthorized parties may do uploads, and impersonation is possible, and this should be addressed by utilizing a shared secret, most likely. HTTP may have its own authentication methods. TLS is supposed to allow for authentication of both endpoints. The SASL protocol may be an option for implementing challenge/response authentication in a standard way, if suitable implementations are available. Use of authorization certificates (rather than authenticating) is also an option. See the Forum Nokia document which discusses installing client authentication cert installation.
• More expressive time specifications. Implement/find Unix time processing functions for Lua. (The "os" module has some, but they may not be sufficient.) These will allow Uploader time expressions to be given in Lua rather than the less expressive language we currently use, and this will actually reduce the size of the binary. Modify Uploader accordingly.
• Call recording would be nice. ContextPhone has this.
• Timed or event-triggered microphone audio sampling would not hurt either. Mobile STK has example code for doing audio recording on Symbian. The Media Recorder API sounds related. MMFDevSound API might also be. Using Qt might also be an option, see QAudioCaptureSource and QMediaRecorder in the Multimedia API of Qt Mobility, and http://qt.gitorious.org/qt-mobility/serviceframework/trees/master/examples/audiorecorder for an example application.
• More sensors: lock status, visible WLAN nodes, light status, new email status, accessory mode change, …
• As an optimization, the Symbian local server interface should be updated to create only a single Lua state instance per session, rather than one per command. This also increases code duplication as it then becomes possible to give some Lua definitions only once per session. The Launcher might be modified to take advantage of this, to create a session only once per command sequence.
• The N97 supports a new OOM Monitor Client API. We might want to be using this for better system-wide low-memory condition handling.
• Sandbox mobile code. Add privilege support to Lua VM. Flag to VM and checks to dangerous bindings. Mobile code may not execute privileged functions. Or it may be enough to simply choose carefully what libraries to make available to a given Lua instance. But any of this will not be useful until significant functionality is implemented internally for Lua, and said functionality requires dangerous operations.
• A software updater application. Would install any required software and certificates, downloading it off the web if not embedded, and fetch configuration information based on IMEI code. This kind of an application is just about the only way to enable a single-SIS distribution due to PlatSec.
• After-checkout source tree preparation. Building the logger, freshly checked out with Git, is not straightforward when relying on standard tools such as ABLD and Carbide. Have a single platform-agnostic script at the root of the repo that produces the generated source files for all components, and also creates standard group directories with project files for some sensible default configuration. This should make it easier to get started. For added convenience, might even generate Carbide projects files if there is a tool that supports their creation.
• A MeeGo, iPhone (jailbroken), Android, or Bada port would be of interest.
• Ovi Notifications API based transport option for remote control. Presumably costs hardly anything if there is any other application also using the API. See the announcement. There is also a white paper and a project page. Still in beta.

Tero Hasu