Thread: Requirements for a Web Front End

Originally Posted by SapporoGuy

@ bugbyte

What is holding you back on going further with your mobile web OS?
Or did I miss something?

@Sapporo Guy - time and web knowledge.

Time - I've purchased an igepv2 embedded Linux board. I'm having a real devil of a time getting Ubuntu on it because I'm Linux-stupid. I'll figure it out some day but not today.

After that, I thought that Sama's Velocity FE would be a good core to put web page skins on. At first, I want to simply get it to run on the igepv2 in the car and serve the pages up to the iPad that way. Later, it can move off the car and onto the net if I want.

I don't really know how all these bits and pieces tie together, so it's going to be a long uphill climb to ever get it working. I just thought that either Velocity or this project are headed in the right direction for a connected car install.

To some extent I can help.
I don't do java ... Which is why I'm a bit hesitant to deal with velocity.
Java as a bqcknd mechanism is great but you have to have people who know what they are or you'll be in the same place as flash. Slow!

I wonder about the use of php in situation, it's great as a asp replacement for the top GUI layer but as a lower hardware level interaction I wonder if java, perl, python or ruby woldnt be a smarter choice.

What are you looking for in a webFe?

I'm experimenting with low power ARM based devices like the Sheeva plug and the igepv2 (similar to a Beagle Board). What I want to do is use Velocity's core and run it on the ARM device. The ARM device will run a web server and I'd like to be able to serve up the look and feel from coded web pages.

Ultimately, those web pages would be accessible not just from the ARM device but from a web server on the net - perhaps using OSDash as a service to update the pages stored on the server or to find/store additional skins for the web page.

It seems to me that with html5, it ought to be possible to build pages that don't have to look like web pages but act more like a web app. The speed may be an issue, but I think with a WiFi hotspot in the car, loading the pages won't take that long.

I haven't looked at all of the functionality that Velocity provides yet. Right now, it seems like the appropriate architecture for this idea. The app itself runs in java. If it is on a Linux based device, scripts can be written to interface with dbus apps that tripzero and Nextabyte Matt are working on like bluemonkey for voltage monitoring, nobdy and obdgpslogger for obdii interface and also for control of the linux library and the fusion brain, for starters.

What I don't know about are the proper technologies to do this stuff.

I'm having a devil of a time learning enough to get Ubuntu on my igep but one day I will figure it out. Then, I want to load apache server on it and see if I can get Sama's Velocity backend running as-is.

Why would we use Velocity FE as the basis for a web front end. What advantages would that give us?

I was wondering, because i was hoping to code a custom frontend for my carputer once i get the hardware. Because i'm only fluent in PHP and some vb6, it would be web based.
I've got OBD2 readings to display on webpages already, justneed to start work on a media section.

- Dont mean to hijack the thread.... back on topic now. lol

There are several Ajax kits to look at mocha, jquery and yahooUI of course there are more. Jquery will basically allow you to do most of the ui in a app like fashion. So this is just an exercise of putting on the right pieces to create that iPhone feel.

There's even eyeOS that can make your browser feel like a desktop.

But, this is not really about UI but more of a backend middle layer issue. Meaning that I have doubts that a server is really where things are headed. Data yes, main program????hmmm ....

Hardware I'm going to agree. A small unit with low level power drain is going to be awesome. But you still need a gpu to provide the final monitor experience.

I may have pointed this out before... or may not have... but there is a better solution than flash and its Qt WRT which is akin to Adobe Air except that it exposes more system level services and supports html5. Basically gives you system level access to services via the W3C "widgets" APIs for location, sensors and more through javascript objects.

I've played around with it a bit and found it to be very fast. I was able to render javascript "evals" faster than I was in Google Chrome (which iirc holds the speed record for browsers). It also supports flash just like a browser would.

I think WRT sports a plugin based system where you can create additional services to expose things like OBD-II etc to javascript objects.

Find out more here:
http://labs.trolltech.com/blogs/2010...ourney-begins/

It's a young project, but it has a lot of potential. Just thought you might appreciate the knowledge even though it sounds like you are pretty sold on flash.

what system level api's does one need?
Or just the ability to run a bash script?

Cool stuff but a bit down the road and probably a major need to write drivers for a large share of hardware .... Bummer

I don't think bug is really into flash but rather looking for a backend to support his server based idea. I am not a flash fan. Cool but just too many apps on flash that aren't programmed to watch memory properly.

I really can't put my finger on this but I'm having trouble thinking that apache/mongrel/lighthttpd (errr, name is wrong) being a center for my in-car.

Moreover, will a server based system be robust enough to support the coming generation of expected net+iOS features that users think they will need?

However, I do buy into the idea that in-car needs to be on-line to access the growing amount of content that is going to coming down the pipes in the future.


Vision: in easy terms -- iOS for the car
a system that goes beyond your regular OS but yet having the power of an OS. Something along the lines of meego but developed as far as CF/OM/RR but yet this in-car is the OS And app at the same time

Well, here's *my* requirements, based on the setup in my car which is igepv2 ARM Linux device with server, WiFi access point, and iPad as control device.

Requirement 1:
The iPad is connected to the audio, thus one requirement I would have is to play the music in the browser.

Requirement 2:
No Flash. For obvious reasons, I'm not interested in Flash but rather html5.

API's/Interfaces:
I've played around a bit with php and there is a dbus connection there. Much of the software that tripzero has been writing for Linux communicates using dbus. For other issues, the ability to run a script would probably be nice.

The things off the top of my head would be OBDII information, GPS information and Fusion Brain control capabilities.

Use of Velocity:
The only reason I bring up Velocity is that Sama has already done some of the work and it is open source. I've had a couple of back and forth conversations with Sama and the model he used to develop separates the user interface from the backend. The Flash is only on the UI side and an alternate UI could be coded that calls the same routines if necessary. Seems unnecessary to reinvent IF some of the groundwork has already been done.

[Edit: I'm on the client-server side of things because my vision for the future is of a core FE that takes care of a lot of familiar stuff, augmented by apps or programs that provide functionality that is outside the core or makes the program monolithic. Example: an FE that controls hvac, does many forms of music -mp3, streaming audio, internet radio, but does not do, say, GPS. That comes from a separate app that you run concurrently and switch to as necessary.

This allows users to add functionality without having to update the FE app. Serving the FE to the client allows a core program to function with a phone, an iPad, a PC, or whatever else you may have that can connect. Each would have it's own screen without having to have its own app. Screens could change based on location or device and new screens would be as easy as selecting a different interface site or file name.]