“HotForestGreen” started May 5th. It is a project I am running in my spare time, when I close the day on the work I am doing for Reed Elsevier. The name is a nice combination of words I chained up and has no deeper meaning as far as I know.
HotForestGreen is a Framework for data-exchange between Remote Objects over local and global Application Clusters.
You can use it to:
- Build the software for Smart Spaces – Using sensors, devices, smartphones, Netbooks and laptops to sense things and make things happen in any space of your choice
- Create Distributed Applications – Allowing people to work together on shared data that updates in real time.
- Socket Servers – To act as communication hubs which can communicate between each other and which automatically take care of load-balancing and re-wiring of communication when more Servers are plugged in, or when Servers bomb out.
- Socket clients – To send and receive data to and from the Application Cluster.
- Automated Service Discovery – When you connect a Socket Client to a Local Network, it will scan that network for available services.
- Remote Object Base Classes – To cover all the basic things you otherwise have to do yourself: to connect to the Application Cluster and to send and receive updates on data in your (Remote) Objects
- Transparent Data Access Layers – To abstract and hide all lower level actions you otherwise would need to create yourself to deal with data. It deals with conversion of data from one type to another (Serialization and de-serialization of Objects), it allows you to directly load human made CSV from the harddisk into Objects and to store and retrieve data from databases.
- Boundaryless development – Where you might start building local Application Clusters in Local Area Networks, HotForestGreen Socket Connections can be configured to connect to any IP address in the word, which can be anywhere in the world. This allows you to create any application of any size, ranging from a room to an entire city or spanning the entire world.
Most of the groundwork of the HotForestGreen framework is done. The basic design to exchange data is very much crystallized. The code to deal with the events and messages to update Remote Objects is written last week. The parser to serialize and de-serialize Clear Text Data Objects has been written and tested this past days. The scanner that scans the Local Network for services is tested and works.
During this and the next week I will finalize the Transparant Data Access Layers and the Socket Client / Server.
From that point on the Framework is ready to build some proof of concepts as described below.
First release date
With the speed of development I estimate to release the first version June 30. That version will include all the basic things you need to build Smart Spaces and Distributed Applications.
The Framework will include several security layers, making sure that Hijacking a Smart Space is taking more effort than it is worth. These security layers will include:
- Exclusive Lists of HotForestGreen Servers – Making sure that the Servers only blabber their secrets to each other and not to a server plugged in by a Hacker
- SSL connections – Encrypting all data transfer by default so that packet-sniffing within the network delivers gobbledy gook instead of clear text data.
- Secured Authentication – With which you can simply setup a standard login scenario where users can not enter your Application Cluster until they have authenticated themselves. Running underneath will be several scenarios that will assure that the session of “user X” can not be hijacked by “user Y”
Source and examples
The Source will be available as soon as the Framework is running with all the basic stuff working. As I started in C#, the first run will be C#, due to some proof of concepts I want to run.
After the C# code is completed I will start working on the Java code.
The code base will come with a set of examples you can run on your own computer(s) to play around with. These examples will include:
- Remote controlling mouse and keyboard from phone or tablet – A simple application where your phone or tablet turns into a remote control
- Changing colors on the screen – This is the basic app for domestic control: where you can change the mood of a room by changing the color of the light using – again phone or tablet computer.
- Working together on data – This app will use the Transparant Data Access Layer to demonstrate a use case where two or more people work on the same data and changes made by one are reflected immediately on the machines of the others.
General purpose and design principles
HotForestGreen is a framework aimed to cover the following:
- Cross Platform – Think of Java and C# at this moment, with applications running on OSX, Android, Windows and Linux systems.
- Distributed Systems – Can be:
- Smart Spaces – Where sensors are monitoring temperature, doors opening and closing and people moving in spaces. Where devices take care of changing temperature, lighting and opening and closing doors.
- Remote controlled applications – Where smartphones and tablets can be used as remote controls, to open websites on a big screen or check and control smart spaces
- Distributed Applications – Think of real time/ad hoc scheduling where updates in agendas are shown immediately when the assistant opens stuff on their local machines, client data is projected immediately on the screen when the client enters the room after being shown in, and so on.
- (Distributed) Remote Objects – Can be:
- Representatives of Arduino, XBee and IoIO (YoYo) devices – Allowing you to “directly” set values on ports and “directly” read values from ports of these Devices somewhere in your Application Cluster
- Databases and Data Records – Allowing you to access data, change it anywhere and push the changes back into the database
- Any object in your code – Allowing you to remote control applications from tablets, phones and other computers and even take over the keyboard and mouse
- Automated Object Synchronization – Whatever changes in one representative of “Object 01” will automatically be broad casted to all other representatives on all other machines in your network and Application Cluster, making it easier to control devices, receive updates from sensors and more.
- Plug and play “Remote Control” – Using basically an extended web browser with a Service Discovery Mechanism underneath you have a general purpose, (mobile) application to “plug into” Smart spaces and displaying all possibilities offered to you as a user without having to install new software
- Up and running in 30 minutes – Taken that you have some programming skills, the Framework should allow you to build a working, distributed application (with data from a CSV source or database) from scratch in 30 minutes.
- Simplified Development for Hardware Geeks – Think of Arduino devices, XBee and IOIO (YoYo). Think of building applications that run on multiple systems to control those devices via Remote Objects representing these Arduino, XBee and IOIO devices. Instead of having to do all the hard work, HotForestGreen take care of most basic things.
- Reduced dependencies – With a built in simple HTTP Server, a framework to synchronize Distributed and Remote Objects, Socket Servers and Socket Clients you do not need to install and configure extra stuff to do the more complicated scenarios for data exchange
- Scalability – Using several principles from “distributed computing”, including Load Balancing, you should be able to plug in as many Servers as you like, add as many Clients as you need, connect to sources and Servers somewhere on the Web and run stuff Locally inside your LAN
- Low cost – A 180 euro Netbook acting as a WiFi hotspot and SmartSpaces Server is already enough to run the Framework. Once tested, probably 90 euro Android Tablets should allow you to lower that price even more.
The history of HotForestGreen is traceable back to 2006 when the first Roomware Server was built by Tom Burger. Even though the principles of that Server were completely different from what you find here (it basically offered a named list of bluetooth devices discovered by the computer it ran on) it has been the direct source of inspiration.
In 2009 I hacked together a “Roomware Socket Server” running on some fixed IP address and operating as a “Event Hub” for Events dispatched from all kind of clients.
In februari 2010 I saw a demo of “Brass Monkey” by InfraRed5, which used the local WiFi and an iPod to act as a remote control for a Star Wars game they developed.
Starting from June 2010 I worked as lead developer on – and wrote the framework for – a big project for Reed Elsevier, using BlazeDS and dealing with relatively complex scenarios regarding Client Side buffering of data and using Data Injection in persistent Client Side objects, to keep things from becoming a mess.
Between 1999 and 2005 I wrote several solutions to generate code and complete Database Content Management Applications from databases and to inject data into databases, without using any database- or table-specific code at all.
Between 2007 and 2009 I worked as lead developer on several multi-lingual Flash sites and developed several ad-hoc solutions to change labels and content in the sites on the fly when the user changed language.
HotForestGreen takes all this and wraps it into a neat package.
Shortlist of what is cooking now
- “Smart Spaces” – The starting point for the framework: rooms, lobbies, squares, homes, offices made “smart” using hardware (sensors and devices) and software
- Local WiFi and automated service detection – The framework runs on a local WiFi network
- Low budget and up and running in 30 minutes – The goal of the framework is to allow developers to be up and running in 30 minutes, using anything from a 200 euro netbook and up as both WiFi hotspot and SmartSpaces Server
- Self configuration, Ad Hoc and load balancing – There is no central Server, multiple Smart Spaces Servers can run one space and the Servers are being designed to be distributed. When whatever Server drops out (crashes or unplugged) or a new Server is plugged in, the Smart Spaces network will reconfigure itself
- Object Oriented, Remote Objects and Data Injection – After some initial conceptual runs using “messages” beginning of May, HotForestGreen is now primarily developed around Remote Objects, using Base Classes to deal with sending and receiving Remote Updates. There Remote Objects are managed within these Base Classes and data – which includes concrete objects – is injected into these Remote Objects, making development of applications a lot easier.
- JSON and XML – Kicking off with JSON one week ago, to serialize and de-serialize Objects and make synchronization of Remote Objects easier, I started to dislike the overhead and redundancy created by the way JSON serializes data. For internal communication between Remote Objects, I started moving to SCSV (Secure/Solids CSV).
- CSV, SCSV and ASCII codes – To reduce the overhead I grabbed back to some old-school formats including CSV and the ASCII codes in the range from <char 0> to <char 32>. Where CSV is kind of OK-ish it can be quite unreliable when the data contains patterns similar to the separators used to distinguish individual CSV values. To avoid this mess, the Framework uses ASCII codes <char 30> and <char 37> which are separators for rows and data cells.
- Bonus: CSV data – As a bonus, the framework can now directly import hand-crafted Excel Data into objects within any application built with it. This is especially handy when you run Mockup Data or when your website or application is multi-lingual. Generating CSV data with Excel is extremely easy (type in values in Excel, export it as CSV). By simply loading the CSV data you can
- SSL – Still in Conceptual Phase, SSL will be one of the extra security layers on top of the Sockets used for communication between Clients and Servers, to make it harder for data to leak to people who can abuse that data.
- Transparant Data Access Layers – Using Reflection, making it easier to get data from- and push data into- databases. Using reflection and some other neat little tricks, most things you would otherwise write out in individual lines is automated. The only things you need to define to make it work are:
- The database connection – To the database you want to access
- The Table or View-name – Of the Table or View you want to access
- The name of your primary key – To identify your records and make retrieving data from- and pushing data into- your database possible