Linux Web Front End Development Thread

Printable View

Show 40 post(s) from this thread on one page

06-12-2009, 07:13 AM
PaulF
Alright, so how about we meet half way and combine these two ideas...
- Create a syntax for grabbing information from the server using jquery.
- On the server, have plugins that are loaded into the query page on-demand.
- Build a direct-dbus plugin for those applications that don't require much processing of information at all.
- Build a second stand-alone daemon for fusion brain that communicates with the current DBUS daemon and include all the features it needs so that it can run with no user interaction and do things when certain conditions are met. Pretty much the features I was talking about for the brain before.
- Make a fusion brain plugin which relies on the daemon I just talked about, rather than the one that just communicates directly with the hardware.
Now any interface that can make web requests can easily communicate through this whole plugin system.

We can all create classes in our favorite programming languages to interface with this server setup.

That way, for setups like mine, the sheeva plug is on all the time, but I also have a full pc in the car with a C# front end. That front end can now easily get information from the sheeva through this system.

Now heres what I want to see on the side of GPS:
On my system, I want the GPS receiver to be hooked up to the Sheeva, but I still want to be able to access navigation programs on the PC... anyone up for writing a windows driver that interfaces with this setup and allows normal GPS communication with GPS apps?
06-12-2009, 07:21 PM
tripzero
Quote:
Originally Posted by PaulF

Alright, so how about we meet half way and combine these two ideas...

Create a syntax for grabbing information from the server using jquery.
On the server, have plugins that are loaded into the query page on-demand.
Build a direct-dbus plugin for those applications that don't require much processing of information at all.
Build a second stand-alone daemon for fusion brain that communicates with the current DBUS daemon and include all the features it needs so that it can run with no user interaction and do things when certain conditions are met. Pretty much the features I was talking about for the brain before.
Make a fusion brain plugin which relies on the daemon I just talked about, rather than the one that just communicates directly with the hardware.

Now any interface that can make web requests can easily communicate through this whole plugin system.

We can all create classes in our favorite programming languages to interface with this server setup.

That way, for setups like mine, the sheeva plug is on all the time, but I also have a full pc in the car with a C# front end. That front end can now easily get information from the sheeva through this system.

Now heres what I want to see on the side of GPS:
On my system, I want the GPS receiver to be hooked up to the Sheeva, but I still want to be able to access navigation programs on the PC... anyone up for writing a windows driver that interfaces with this setup and allows normal GPS communication with GPS apps?
Sounds like a plan :) !

Gpsd will run on the sheva, so you could open up a socket connection to gpsd. I don't know if you navigation app is capable of doing that though... Navit certainly can.
06-13-2009, 03:28 PM
red_parchel

Guys there are many awesome idea's here, and I'll admit I'm not much of a web programer. but i do believe in the open source ideals and i believe there is no need to reinvent the wheel. this said i may have a suggestion for the media side of things, ampache is a web based music jukebox that does a few things, which includes the ability to plug music from the website ON the server [using mpd] or stream music from the server to the client [ether a flash player or via a playlist opened in a local app] .. I feel this model is great and there may be some useable code in this project. and if we decided to go this route I'd be more than willing to help in this department. If you guys decide to go another route then heck i can help out w/ something else too!

Hope there is something useful in there! I like the direction you guys are headed!

and i like the idea of being able to keep it all seporated .. if i teathered my cell phone to the plug i could montior my car from my home webbrowser [it'd feel like a race car driver with a team monitoring the car!!!]
06-13-2009, 08:36 PM
cgalpin

On a related note, I want to mention an idea I have regarding the FB. I'll preface this by saying I don't know jack about OBD...

For anything I use the FB for that has OBDII analogs, I'd like to create a ODII simulator which servers the data collected just as if you'd get it from an OBDII vehicle.

The benefits are

1. I suspect most people wanting to collecting these things (rpm,temps,maf sensors etc.) will be able to leverage this with at most configuration changes.
2. Those using the FB can then leverage all the OBDII based tools out there for display, including this web based stuff
3. We attract a larger pool of people interested in this web based stuff if it's not just about FB interaction.
06-13-2009, 08:53 PM
Bugbyte

Quote:

Originally Posted by red_parchel

Guys there are many awesome idea's here, and I'll admit I'm not much of a web programer. but i do believe in the open source ideals and i believe there is no need to reinvent the wheel. this said i may have a suggestion for the media side of things, ampache is a web based music jukebox that does a few things, which includes the ability to plug music from the website ON the server [using mpd] or stream music from the server to the client [ether a flash player or via a playlist opened in a local app] .. I feel this model is great and there may be some useable code in this project. and if we decided to go this route I'd be more than willing to help in this department. If you guys decide to go another route then heck i can help out w/ something else too!

Yes! This is exactly what I had in mind. The ability to access data or information regardless of location. In some cases, it is in the car - OBDII data on the Sheeva, for example. In other cases, it is on a home computer with a web server like ampache. In other cases, it is out on the web like traffic info or whatever.

The key is to be able to handle all of the different locations. I think a web based front end show a lot of promise in that regard.
06-13-2009, 09:19 PM
PaulF

Quote:

Originally Posted by cgalpin

On a related note, I want to mention an idea I have regarding the FB. I'll preface this by saying I don't know jack about OBD...

For anything I use the FB for that has OBDII analogs, I'd like to create a ODII simulator which servers the data collected just as if you'd get it from an OBDII vehicle.

The benefits are

1. I suspect most people wanting to collecting these things (rpm,temps,maf sensors etc.) will be able to leverage this with at most configuration changes.
2. Those using the FB can then leverage all the OBDII based tools out there for display, including this web based stuff
3. We attract a larger pool of people interested in this web based stuff if it's not just about FB interaction.

Let me just clarify to make sure I understand...
You want to make a driver which pretends to be an OBD reader but is actually taking in values from another source?
06-13-2009, 09:21 PM
PaulF

[Nitpicking]

Quote:

Originally Posted by Bugbyte

...with a web server like ampache...

Apache is the web server, ampache is a web application for apache which does sound stuff.
[/Nitpicking]
06-13-2009, 09:48 PM
cgalpin

Quote:

Originally Posted by PaulF

Let me just clarify to make sure I understand...
You want to make a driver which pretends to be an OBD reader but is actually taking in values from another source?

No, not a reader but a provider. A daemon that provides a serial port that you connect to and talk the obd protocol. But the data it provides doesn't come from an ECU but from a FB. So I guess it simulates the ELM protocol.
06-14-2009, 03:49 AM
tripzero

Quote:

Originally Posted by red_parchel

Guys there are many awesome idea's here, and I'll admit I'm not much of a web programer. but i do believe in the open source ideals and i believe there is no need to reinvent the wheel. this said i may have a suggestion for the media side of things, ampache is a web based music jukebox that does a few things, which includes the ability to plug music from the website ON the server [using mpd] or stream music from the server to the client [ether a flash player or via a playlist opened in a local app] .. I feel this model is great and there may be some useable code in this project. and if we decided to go this route I'd be more than willing to help in this department. If you guys decide to go another route then heck i can help out w/ something else too!

Hope there is something useful in there! I like the direction you guys are headed!

and i like the idea of being able to keep it all seporated .. if i teathered my cell phone to the plug i could montior my car from my home webbrowser [it'd feel like a race car driver with a team monitoring the car!!!]

Audio prioritization
Moblin has a project they call "Audio Manager". For nGhost3 we were going to write a simpler version of the same thing. It makes sure that the sound device isn't going to be used at the time by other apps. Whatever backed we chose for audio playback, it must be able to tie in with this system.
06-14-2009, 09:41 AM
PaulF

Quote:

Originally Posted by cgalpin

No, not a reader but a provider. A daemon that provides a serial port that you connect to and talk the obd protocol. But the data it provides doesn't come from an ECU but from a FB. So I guess it simulates the ELM protocol.

By reader, I meant physical reader because that is what any OBD program would see it as. ;)

Yes this would be very cool, but I can't imagine the programming involved...

Show 40 post(s) from this thread on one page