Linux Web Front End Development Thread

[PaulF]

In this thread here:
http://www.mp3car.com/vbulletin/linu...-fun-n00b.html
Myself and a few others were talking about the sheeva plug in a car environment. If you don't know what a sheeva plug is, it's a tiny, powerful arm-based computer made by Marvell and has only an ethernet port and a usb port for input/output.

All of this sparked the idea for developing a web based controller for things such as:
GPS, OBD, Fusion Brain

There are already linux daemons/back-ends for all of these.

What we need to do now is decide on how we want to use these things.

On the application as a whole here are my goals for the project:

• Customizable, right through the web interface
• Plugin-based
• Single timer/ajax request.. make request intervals customizable by plugin
• One actual html page, all information exchange is 100% ajax
• Javascript based "pages" - more like "tabs"
• Simple information exchange/update type of language/standard
  
  • The javascript side will make some sort of "ask for" type queries each on a particular update interval, with a list containing things to ask for
  • The server side will send back the information in javascript using some syntax like getPanel('GPS').runCommand('UPDATE:COORDS:50.03,40 .21');
    
    • Basically on the javascript side, each panel will define their own "runCommand" function however they want and their server side functions will be programmed to tell the php responder file what to output

Basically once the main interface is done, people can start developing plugins for it. Such as a plugin for gpsd, one for fusion brain or maybe even music control. Anything anyone can think of.

My biggest interest in this project is the Fusion Brain part and heres what I would like to see happen:

• Have an interface for entering rules into it
  
  • Page where you say if this, then this
  • 'if this' means check a reading from a 'raw' sensor or 'logical' sensor
  • 'then this' means run an operating system command or send something to connected browser sessions
• Raw and logical sensors
  
  • This is something I've dreamed up
  • Raw sensors are sensors physically on the fusion brain
  • Logical sensors get information from something and give it out a modified value
    
    • They can get the readings from raw sensors
    • They can also get information from commands or sockets
    • They can then output it as a different value

We'll probably need to make a second daemon or expand fbd to allow for these rules and logical sensors.



Now heres the fun part for all of you reading this... tear me apart in my ideas. I'm pretty good at programming for this whole interweb thing, but I know there are people out there with better ideas. Suggest better ways, criticize me, whatever. Anything that sounds a little strange, question it, even if you can't provide a better option. Please, rip me apart before anyone starts coding.

Also suggest any features you want to see in the future of this interface as they might require a critical change in this foundation.

[PaulF]

A little more of the planning of this...

It would be very slow and consume a ton of CPU if every time the front end asked for something it loaded a php file which checked a plugins folder, loaded all the plugins, found the plugin you needed and then asked it to process the command.

So after doing some research, I've realized that it IS possible to make a php daemon. Nice.

So now I'm thinking about using mysql as a middleman for information. This way, the php daemon will be constantly processing all information that needs to be updated frequently and storing the values in a mysql memory table for quick access.

There will be three memory tables. One will be for storing data that is updated quickly. One will be a client queue with a list of javascript commands for the client to run. They will have a datetime field to go along with them, so that if multiple clients are connected they can all get the "global" updates. There will be another table for server commands.


The main daemon will start by reading the plugins directory for plugins to this application and then make daemons for each of the plugins. As the daemons run, they constantly update the mysql tables.

The page generating javascript responses will then grab all the javascript commands from the memory tables and will additionally perform any tasks it was asked for by the client. In doing these tasks it gets any information it needs from the data table.

Again, rip me apart.

[cgalpin]

I think only data should be getting passed back, not commands, and let the front end have the display logic. For javascript you might as well use JSON, and one reply with a bunch of data updates for everything being monitored in it would be the most efficient. Data can be obtained very quickly from the existing backend daemons via dbus so I don't think this needs mysql or an additional daemon (although I do think any data logging/persistence on the server side should use a database and if the frontend is getting historical data then the database would be the place to get it).

But If were going to discuss having a headless system, I think it makes the most sense to be able to share the same communication protocol between any frontend and the core server, not just web. For example someone might want to develop a flex frontend, or a native iphone app for example. Right now that's dbus, so maybe something else isn't needed and the web/javascript front end just has a thin php layer to make dbus calls and the daemon is apache.

[PaulF]

I've now figured out how plugin development will work also.

In the plugins folder there will be a folder for each plugin named after each plugin.

In each folder there will be four mandatory files:

• daemon.php
  The programmer will not need any knowledge of creating daemons in php.
  They will simply need to make a class with the name of the plugin (same name as folder). In that class there will be two mandatory methods.
  
  • buildDaemon()
    This method will initialize everything at the start of the launch of the daemon. It will do everything that only needs to be done once.
  • runOnInterval()
    This method will run every x milliseconds from the last time it ran.
    That x will be specified in the settings.xml file
• responder.php
  When a client asks the server to do something for a particular plugin, this file will be included in the response. It should have a method called getResponse($command)
  getResponse should then do all that is necessary to make a good response and then return it in a string.
• client.js
  Required to make a javascript object named the same as the plugin upon being loaded which is required do have a function called buildPanel() which will be called by the whole controlling system upon page load. buildPanel() should use either innerHTML or DOM to give its panel contents. It is also required to have a function called startInteraction(). This function will be called once all plugins have been initialized and built. The purpose of this function is that plugins can interact with each other if they want to. startInteraction pretty much just sets up any talk that needs to happen between plugins right after the page is loaded. There will be functions built into the main API which will check if another plugin is loaded. This function can be empty if not needed.
• settings.xml
  You know...

The plugin can also store any other images or files it needs in its folder and there will be functions/methods in the API allowing it to get the location of its files.

[PaulF]

Woops, we posted at the same time.

I think only data should be getting passed back, not commands, and let the front end have the display logic.

My idea of commands getting transfered were pretty limited. Basically I was suggesting one response with a bunch of lines of javascript in it which would get evaled.

So in a response it might say:

gps.update("coords:57,50");

and then gps object in the javascript would have the logic of displaying that. This way we don't need to serialize data between the server and the script. The plugin processes it any way it wants to.

For javascript you might as well use JSON, and one reply with a bunch of data updates for everything being monitored in it would be the most efficient.

Yeah that was basically my plan, although maybe not necessarily with JSON. Sorry if I wasn't quite clear on that. Yeah I don't want a ton of responses going back and forth.

Data can be obtained very quickly from the existing backend daemons via dbus so I don't think this needs mysql or an additional daemon (although I do think any data logging/persistence on the server side should use a database and if the frontend is getting historical data then the database would be the place to get it).

I realize this, however I figured it would take longer to hit up dbus every second to get data from 10 different daemons and process it. The idea of a backend daemon is so that when the client asks for data, it's all already waiting there for it to be asked for, so the response takes several miliseconds rather than several hundred. Also this way, say an equation needs to be applied to a temperature reading in the fusion brain, that equation can happen before it gets sent so the client doesn't need as much work. Also, if say data is needed from more than one input but only one number is output, then transferring the multiple pieces across the internet would be a slow down when only one needed to be sent... some clients like phones and pdas will have limited processing power.

But If were going to discuss having a headless system, I think it makes the most sense to be able to share the same communication protocol between any frontend and the core server, not just web. For example someone might want to develop a flex frontend, or a native iphone app for example. Right now that's dbus, so maybe something else isn't needed and the web/javascript front end just has a thin php layer to make dbus calls and the daemon is apache.

The problem here is that dbus is quick for moving data around within a computer, but it may be more information than is needed to make it across the internet.


What if this was done: PHP daemon gathers all information needed and a query page outputs it to xml which javascript, or any other language across the internet can access and display?

[PaulF]

And actually, screw XML, you're right, let's use JSON to transfer information.

[tripzero]

I probably don't quite grasp the entire vision of what your trying to do, but let me explain what I had in mind and you can probably tell me if we are on the same page of not:

Main Page
* Does the initial scan of the plugin dir, displays a list of plugins as icons/pics/whatever.
* Allows user to load the plugin he wants with a single click

General Plugin Function
I think a plugin should be able to use ajax or a database however it needs. If there is helper code from the "frontend" (i'll call it core framework), then great.

* Connects with daemon(s) that is needs data from.
* Collects data, some may be stored it a table
* Displays whatever data it needs/wants

GPS Plugin
If we think of the use-case: the user will probably be connecting to the web server via a smartphone, MID or similar device. This device likely already has GPS, routing, bookmarks, etc. This makes duplicating all the functions of GPS rather pointless. So what data do we display?

* Speed, maybe max speed the you've ever gone? Average speed, etc...
* Total distance traveled. Could be interesting...
* Other GPS data: Altitude, Lat/Lng, Heading, etc.
* Could display current data on a Google map with optional traffic, etc overlays.

GPS + OBD-II Plugin
Same thing as the GPS plugin but combines relative data with the OBD-II Plugin. OBDGPSLogger keeps some pretty cool log statistics. It may be cool to tap into that functionality. It uses sqlite for the db I believe.

Fusion Brain Plugin
I agree that a programming interface should be made with a simple language/script file that will save the behavior into.

The fusion brain plugin will probably be two fold:

* Programming interface
* Status/Control interface

Music Plugin

This page may be different also depending the use case. Does the music plugin merely provide an interface to stream the smart device's music through the car via bluetooth/upnp, etc? Or does it just provide a means to play music from the car's storage? I think it should do both.

* Page for configuring bluetooth streaming
(and/or)
* Page for configuring UPnP streaming
* Page for playing music off of the car's storage

Backend Requirement
We are obviously missing a media playing backend. OpenICE does have one planned for nGhost3, but development hasn't begun on that piece yet. OpenICE will probably piggy back off of a few carefully modified moblin service. More planning needs to be done however.

[tripzero]

I think only data should be getting passed back, not commands, and let the front end have the display logic. For javascript you might as well use JSON, and one reply with a bunch of data updates for everything being monitored in it would be the most efficient. Data can be obtained very quickly from the existing backend daemons via dbus so I don't think this needs mysql or an additional daemon (although I do think any data logging/persistence on the server side should use a database and if the frontend is getting historical data then the database would be the place to get it).

But If were going to discuss having a headless system, I think it makes the most sense to be able to share the same communication protocol between any frontend and the core server, not just web. For example someone might want to develop a flex frontend, or a native iphone app for example. Right now that's dbus, so maybe something else isn't needed and the web/javascript front end just has a thin php layer to make dbus calls and the daemon is apache.

I think you nailed it on the head. The daemons already have an enabled and accessible messaging system in place (DBus). They were written (at least the ones I wrote) so that any interface can display the data. I don't think it makes too much sense to put a man in the middle when you can go from server to client in one request. Let the plugin decide what data he wants and how often he will get it.

Again, I may not understand fully understand how you are planning this all works...

[PaulF]

Here is a picture of an ugly version of the eventual outcome of this:


Alright have only one page on the client side of this. Javascript and Ajax do all the work, no page loading, only ajax loading.

Have a panel that each plugin can control. Allowing the user or programmer to set html tags as necessary and unnecessary so that you only see the necessary tags until you click more. Each plugin would have virtually full control over its panel.

My idea on the php backend to this would be to have all the information get processed on the server pretty much and then just passed along to the page through ajax and json.

Then on the server, each plugin would have its own way of connecting to any application it wants to. That way the plugins on the server can grab raw data from the fusion brain and process it and one "application" could be designed to read specific information from the brain. Another app other information.

Instead of just connecting to a dbus daemon, that plugin can be connecting to anything in any way... dbus, sockets, JSON, xml, log files, web page parsing, Amazon AWS. Then the user can customize how that page looks with a bunch of apps. Like:

Engine Temp app
GPS location (+ map when you click more)
Speed app
RPM app

Or bigger applications which include more data.

This way each plugin does all their own information parsing on the server and then when the client requests info it all gets sent, processed and output by javascript. This way on the page, you see the current speed and gps position actually changing in almost real-time.

EDIT: Oh and in that picture, for fusion depending on the plugin and settings it can be outputting human readable numbers like 60 degrees and 3 feet instead of voltages.

[Bugbyte]

Recognizing that I don't have the technical depth to enter this discussion, I will still bravely forge ahead and offer a couple of ideas as design principles.

1. From what I can tell, the basic approach outlined is the right way to go. The phone or mobile device calls up a web page that resides on the Sheeva and can use it as described in earlier posts.

2. However, it would be good to make sure one is not completely tied into this structure. In the future, someone may want to make a device specific app that interfaces with the plug. I'd like to see some kind of 'container app' that runs on the smart device that provides basic interactive functionality as described, but would run on many devices. (Perhaps this is in java).

The reason I'd like to see this is that it would increase the adoption rate of the software once it becomes more full featured. Being able to run it with near identical functionality on an iPhone or a Windows mobile device or a netbook allows us to break that dependence on the device and concentrate on the functionality. The installed user base goes up quickly because almost everyone already has a mobile phone and a Sheeva plug is very inexpensive.

3. In the same vein as device independence, keeping the option open to get the gui screens from the web as opposed to off of the Sheeva itself, opens the door to a web site where one can arrange the interface and mix and match functionality, commit the changes, and then see them appear on the phone when the run the 'container app'. This is the most exciting possibility, especially when you combine it with the possibility of adding services to the container app from the cloud. (Think of network based plug ins running on a server vs. ICE2 plugins running on the Sheeva).

I realize I don't know much about how all this would work, but wanted to offer my thoughts on it as design principles. I just think it would catapult the user experience forward if the average user is able to customize not only the GUI but the individual functionality of the mobile applications through a web interface.