FrontlineSMS Architecture

[Alex Anderson]

For those trying to get their heads around the FrontlineSMS source code, here's a quick breakdown of the FrontlineSMS architecture as it stands, and some brief notes about how we plan to move it forward.





FrontlineSMS Core

The "FrontlineSMS Core" comprises the central controller of the FrontlineSMS system, managing interaction between phones, stored data such as contact details, and an end-user's view and manipulation of the system. The core is a mandatory part of any FrontlineSMS system, but it should be possible to extend or replace any other part of the system.


SMS Device Manager

The SMS device manager is the interface through which all SMS messages are sent and received. It manages connections to hardware SMS devices, such as mobile phones connected via cable or bluetooth, and software SMS devices such as Clickatell's HTTP service.

Hardware management is currently implemented via SMSLib, an open-source Java library allowing connection to AT- (Hayes)compatible devices. We're also planning to add support for Symbian phones and newer (FBUS) Nokia Series 40.

On the software side, FrontlineSMS currently supports sending SMS messages via Clickatell. In the works is support for sending and receiving with IntelliSMS. We are also modularising the software SMS device interface to allow for 3rd-party plugins to be added more easily.


Data Controller

The data controller handles connections to the underlying database. Currently, SQLite and MySQL are fully supported. In the future, we are hoping to move database handling to a 3rd-party library, which should massively improve the supported platforms. We also intend to implement a memory-only Data Controller to allow for running FrontlineSMS with increased privacy.


UI Generator/Controller

For the current UI layer, FrontlineSMS uses the ultra-lightweight Thinlet. It's a great little library - fast to get going and with great internationalisation support - the FrontlineSMS UI is already translated into 8 languages. Project contributors modifying this should bear in mind that we will be looking to modularise the UI code in the coming months.


External Systems

Keywords can trigger FrontlineSMS to make a call over HTTP or on the local machine with details of the message received. These systems can then process the message data, and respond to FrontlineSMS with instructions to send new messages.


FrontlineForms

FrontlineForms is a proprietary add-on for FrontlineSMS allowing a mobile Java client to connect to FrontlineSMS and share data with it. More details of FrontlineForms will follow in another post.


FrontlineSMS relies on many free and open source projects, and is grateful to them all:
SMSLib, Thinlet, RxTx, SQLiteJDBC, MySQL, Log4j, Silk iconset.


You can get to the source code from SourceForge.

[Florence Scialom]

Hi Drabo,

Thanks for your comment here. We are currently developing Version 2 of FrontlineSMS, and it will be available this year. When it is available to test in open beta we will be sure to share the news on the forum/ via our blog. In the meantime you can check out the source code of the current version of FrontlineSMS and join our developer mailing list via the Developers page on our website here http://www.frontlinesms.com/for-developers/.

I hope this is helpful. Thanks for your interest in this.

Best,

Flo

[drabo sounkalo]

I am interested in the use of form FRONLINESMS. til there is a version 2 under development? There are things to see and want to know how I can intervene to improve it?

[Marc Maxson]

I am really excited you support MySql integration. What specific documentation do you have for options on exporting Frontline data into another existing MySql database? do you have plans to automate that kind of synchronization as a scheduled task?

[Tom MacWright]

Are there any plans to nix the 'Request a Download' process when the open-sourceness of FrontlineSMS is better revealed? Since it's redistributable and I really hate giving away personal information, it seems like an odd and unnecessary kink in adoption (after all, most software is installed via a quick download or even just 'port install x').

Will there be any information on the main site about downloading the source easily? It's pretty standard-practice among these kinds of tools.

[Ben Whitaker]

Hi Katrin,

License is LGPL
(chosen because some of our libraries, such as the serial port accessor from SUN wouldn't fit under GPL)

Details of how to download are all on sourceforge:
https://sourceforge.net/projects/frontlinesms/develop

To check out the source code enter the following URL in your Subversion SVN client:
https://frontlinesms.svn.sourceforge.net/svnroot/frontlinesms

You don't need any logins, this is open to the anonymous public for download.

Of course, the new developers group will cover this in more detail once it is launched.

[Ben Whitaker]

yes bART,
there isn't a single file - SVN will check out all of the files individually.

The standard java build should work on the Mac, and I think there's a build target for mac too?

[bART Sullivan]

and how large is the file? Should I use the SVN?

[Alex Anderson]

Hi bART! The HEAD of trunk/ should be stable, so I'd recommend using that.

[bART Sullivan]

Hello guys - which version should I download to run on my mac? There are some features in the UI I'd like to tweak.

[Tom Godber]

Hi Martin,

I'll echo Alex and say thanks for the feedback - it's always good to have people get involved, and if you wanted to be really helpful and create those Linux installers that would be even better! It's on our to do list, but behind some more critical features right now.

I think there is a little misunderstanding which comes from you being a web developer - it is worth noting that FrontlineSMS is foremost a product designed to run on the widest possible array of hardware, inlcuding 486s running Windows 95, with limited connectivity. If you reconsider what you have said - all valid for a server-based webapp - whilst considering it as a desktop app with this target userbase, perhaps the design decisions will make more sense. I'll expand a few points here for anyone who is interested in our architectural thoughts:

Spring is a wonderful framework - we use it all the time on servers - but it carries with it considerable overhead (megabytes in the jar and processor cycles at runtime) which are not acceptable for the limited benefits FrontlineSMS would gain from it.

The application does use some MVC separation concepts, but we have made sacrifices to work with Thinlet which is an incredibly good lightweight GUI framework that runs with very low hardware requirements. There are certainly points where the architecture can be improved, but our overriding concern has been to provide maximum features and performance on minimum hardware and budget. Use of features like generics has often been guided by the libraries we are working with - you will find they do show up in the parts of the code with few/modern external library dependencies!

Java Web Start is great for people running modern PCs, but not a priority given what I've said about our target market. It may well happen, but we have to consider what is of benefit to the widest possible userbase when prioritising these features!

In a web server context, MySQL is fairly scalable where SQLlite may not be - however given the volumes of data passing through a typical FrontlineSMS system either is quite up to the job! Similarly, multi-tier architectures and some of the other concepts you mention make sense for a server, particularly one which may need to be clustered or distributed over multiple boxes, but actually they impede performance and effectively reduce scalability on the low-end hardware we're targetting.

Hopefully that explanation makes sense - all valid criticisms from one perspective but we think we've generally made the right choices overall!

As for Ning vs SourceForge vs Google vs mailing lists - Frontline existed on Ning before we were ready to fully open source, and we've just kept using it. Some people prefer one, some the other - really it's down to personal preference (I personally prefer Ning, for what it's worth). Hopefully the actual underlying platform is pretty irrelevant as long as it is capable of delivering good support and communit co-ordination!

Best regards,

Tom Godber, Masabi.