Mediator 0.2 roadmap - NodeJS-based "localhost" middleware to TelaSocial

First version prototype 0.1:

The Mediator [1] is a NodeJS-based application that works to support TelaSocial run-time environment. The Mediator was initially created to keep a means to serve remote feeds ( content avaialable via RSS, Atom, and more ) using a middleware server. The original code was created as a solution to allow multiple clients to to load feed content from external sites. The network scenario was the following:

a) 12 web-based kiosks installed with access to a specific subnet without full internet access
b) Another server, available in the same subnet, was able to access content from the internet.

So the Mediator app was placed in b) server and it used a rules configuration [2] file to fetch remote content ( RSS, Atom, etc ) and keep it locally in the server. When a given client app, a kiosk, requested data, then it served from the disk via HTTP.

Proposal to update 0.2:

In the above scenario the application was running in a separated server. For 0.2, the ideia is to run this application in the same computer that runs TelaSocial client — so it will work as a run-time engine to support the client app. It will maintain persistent information about remote channels and also can be used as a means modify and perform some configuration in each client. The following features are planned to the release 0.2:

Cache and Proxy Component: we continue to keep the channel concept, which means we maintain a cycle of fetches from the Web, using HTTP, specifically for RSS, Atom and other data formats, and we maintain in the local disk ( persistence of feeds ) however we want to do a better job related to how to keep the logs. As an example we want to know if the remote feed was available and we may also think about alternate actions in case a certain feed is not available. We maintain the idea of the rules configuration [2] file;
Cache and Proxy Component: Functional Resize HTTP Image component: we need to design a solution to be able to use the Mediator as a proxy tool to retrieve images to the client. So, for example, when the client requests a given image, it may decide to go via this component so the image is adequate to the client;
UI to access logs: we neep some sort of UI to see what is going on in terms of all the files served and also loaded from the network;
Client Process component: Today this functional aspect is covered by a Python code. We are considering bringing this function to the actual NodeJS-based code, the Mediator component. So to check if the client software ( TelaSocial XULRunner-based app ) is running and its memory footprint usage and we may act depending on conditions, for example, if the process is dead ( which also is our solution for first time boot ) or when memory usage goes higher of certain amount;
Log for process management: log everything, how many crashes, system boots, and more if there is more important things to log;

[1] https://github.com/taboca/TelaSocial-Mediator

[2] https://github.com/taboca/TelaSocial-Mediator/blob/master/config.json