OSDash Genesis Thread - Was: OpenVIS - The Open Vehicle Infotainment Service

[Heather]

3 words: OpenStreetMaps. You are right though, it'll be not entirely useful until large numbers of people use it. I don't expect this project's success overnight. If it takes a couple years to become really useful, that's okay with me. I realize that none of this will be very useful to the 90% of carpc users. But if the trend continues, it'll be very relevant very soon.

I agree, focus on what's most useful at first.

I'd be great to have another c# dev on board besides myself.

If we can slowly chip away at the map issue - over time we will have something that will be use full to all.

[justchat_1]

I wasn't implying long term it won't work....i was referring to short term. Very few users will be using navit until it can actually function somewhat reliably which i'm sad to say doesn't look like anytime soon. I'm trying to think of some creative solution to get something going before that, using any kind of gps software, without infringing on their terms of use. Maybe using intersections to trigger segment changes and then using a random gps cordinate between the two? it would avoid transmitting their map data but then the question is how well do streets from teleatlas or navteq line up with open street maps?

[tripzero]

I wasn't implying long term it won't work....i was referring to short term. Very few users will be using navit until it can actually function somewhat reliably which i'm sad to say doesn't look like anytime soon. I'm trying to think of some creative solution to get something going before that, using any kind of gps software, without infringing on their terms of use. Maybe using intersections to trigger segment changes and then using a random gps cordinate between the two? it would avoid transmitting their map data but then the question is how well do streets from teleatlas or navteq line up with open street maps?

OSM maps and navteq maps should align up near perfectly. Most maps share common ancestry at least in the US (Government TIGER data) and they should be as accurate as the GPS system itself. The server only really cares about the coordinate and the speed. The server can either reverse geocode the coordinates into human readable addresses and return a list of "trouble areas" and the user can view it as a feed, or it can return a raw list of coordinates and its speed and have the navigation client worry about reverse geocoding and applying distortion to routes etc. I know navit can do this (allbeit in a not so user friendly way yet), that'd be cool if other navigation apps could take advantage of the data as well. Maybe if we build it, they will?

This is an implementation detail that we can worry about later. Right now we need to figure out what kind of resources we have and come up with a basic architecture. I'll try to come up with some documentation tonight on how it should all work. Then we can start putting some code down.

[justchat_1]

Yea thats true..then in that case we can make this nav system independent. Each client takes average speed per segment, picks a random gps cordinate along the segment and then submits the two (without any copyright map info being transmitted). The server should reverse geocode the point into a street segment using osm (aka i-95 between exit 5 and 6) and then submit that to the storage database. I would say start by tracking 3 hour blocks per segment and as the project grows that can be shrunk.

Yea documentation sounds good...probably some easy xml coms? Only question I had was how should we handle user authentication? That should probably be part of the basic architecture.

oh and side note: we should have the openOBD project web interface online in a day or two so you can add vin and dtc lookup to the list of services

[tripzero]

Okay, so I've worked a little bit on doing some high level architecture of the system. What's cool about this, and what should get every FE author excited and involved is this creates a unified plugin architecture for all frontends. That means plugins written to interface with the cloud on RR will work on nGhost etc.

The Client:

The client will be a thin .NET assembly (in c#) that basically does plugin management and provides interfaces to the FE specific code that will use the assembly. The plugins interface with different servers. One plugin (ie. plugin "A") could goto the OpenIVI server for traffic. While another plugin could go directly to google for the traffic data. It's up to the user to select which plugin he prefers to use.



The FE specific integration would be something like a service daemon for LinuxICE that exports the interfaces over dbus for other apps to consume. Or it could be a RR plugin.

The Server

The server will be a collection of individual web services on the front, and database and user account interfacing on the back. For user account management, the simplest and most secure approach is to integrate with vbulletin (in the case of mp3car) or drupal/joomla/random CMS. That way the user, who already has an account, can use the existing account management and security features of the existing content management system. User account interfacing will be very site specific, but there is no reason why OpenIVI can't provide a plugin to interface with a few of the more common ones.



The server is going to take more thought on it's implementation, but this will suffice for now: It should provide an interface to multiple plugin-based-backends. That way site implementations can choose at will to swap out backends with other backends that better meet their requirements.

[tripzero]

oh and side note: we should have the openOBD project web interface online in a day or two so you can add vin and dtc lookup to the list of services

Excellent. The thought had crossed my mind but i neglected mentioning it.

[justchat_1]

This may not be phrased the best way but a lot of the client side architecture is actually concepts built into openmobile. We already allow data provider plugin x,y or z to pump data into a standard interface and then data can be retrieved by other plugins using exactly the same standardized interface. I don't want to shoot anything down but it seems like it might be a tad bit more client-centric then I had envisioned. For my FE at least that would involve doing everything twice for little benefit, and for others that is still a pretty sizable implementation requirement.

What about the possibility of focusing more on the server side and using standardized coms? If you use xml (especially rss) for server responses it becomes trivial to implement. Otherwise you have a performance penalty for an abstraction layer that may not be necessary. I guess it comes down to scale, I saw this as something that could be up and running in a few days given hosting space and a database. For Example:

[tripzero]

I was thinking of using WCF-style web services standardized on the SOAP protocol. These are trivial to implement in .NET and no xml/protocol needs to be known by the client or server. VS and even Mono can generate code from the web service's. It also supports SSL and other forms of security which is nice.

If you haven't looked into WCF, do so. It's pretty nice.

[justchat_1]

I've used soap before but was never happy with the amount of bloat it generated (not a big deal on high speed connections but over 3g it certainly could). One of the projects I worked on was a large movie database. After transitioning to SOAP web services transmitting meta data for 100+ movies took almost 1.5x as long. We could definitely go that road it just wouldn't make the rr guys very happy. It also would limit the services offered.
Any word from mp3car on what resources they're making available?

[Bugbyte]

One thing that I would encourage is a standardized 'wrapper' for program communication and a 'payload' of the actual information.

The purpose of the wrapper is to permit standardized exchanges to take place regardless of whether the program understands the payload information or not. That allows users the flexibility to do what they want in their own FE's while still making it adhere to the standard.

Perhaps we could also see whether there can be agreement on some SIMPLE concept definitions like 'next track' or 'pause' or what constitutes a playlist or the definition of a gps point and add that to the standard

Even if we can't, providing a wrapper allows those who don't agree on the definition to send their own version of that data inside the standardized packet and allows it to be handled accordingly. And, using a wrapper allows the standard to be flexible and extendable.

I'm having a conversation with mp3car tomorrow about this project. I'm going to ask for server space and propose the idea that Kev has for the user ID and management to be associated with the current user I.D. I'll also ask for some help from their web guy to build a simple web interface for managing the configuration of the apps.

They already understand that this is not a proprietary system and want to contribute to a crowd sourced project. Is there anything else we want to ask for from them?