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

for these types of services where you're not really passing sensitive data which requires the extra features of the WS-* stack, you're probably best using RESTful services. WCF has full support for publishing and using RESTful services, and integrating with them is easy enough for any platform/technology.

Although not as architecturally sophisticated as the effort described here, I've been running several prototype plugins on Centrafuse3 that provide live traffic, traffic cameras, RSS feeds, weather, Google calendar, location-aware search, personal notes and assorted streamng media. All of the information is derived from web-based APIs of one form or another.

If your effort is to try and aggregate information and resources relevant to a carPC users, and present it as an RSS/REST/Web Service/XMLRPC feed....its already being done. Almost all of Google, Yahoo and Microsoft's services are available as APIs. Trafficland, BeattheTraffic.com and others provide real-time traffic updates, EVERYBODY has an RSS feed nowadays. What's the difference between writing a plugin that accesses your service and writing one to access Yahoo?

What is the value added?

VegasGuy

Quote:

---

Originally Posted by VegasGuy

Although not as architecturally sophisticated as the effort described here, I've been running several prototype plugins on Centrafuse3 that provide live traffic, traffic cameras, RSS feeds, weather, Google calendar, location-aware search, personal notes and assorted streamng media. All of the information is derived from web-based APIs of one form or another.

If your effort is to try and aggregate information and resources relevant to a carPC users, and present it as an RSS/REST/Web Service/XMLRPC feed....its already being done. Almost all of Google, Yahoo and Microsoft's services are available as APIs. Trafficland, BeattheTraffic.com and others provide real-time traffic updates, EVERYBODY has an RSS feed nowadays. What's the difference between writing a plugin that accesses your service and writing one to access Yahoo?

What is the value added?

VegasGuy

---

At least 4 services proposed so far are not available anywhere else...I would call that value added.

Quote:

---

Originally Posted by SFiorito

for these types of services where you're not really passing sensitive data which requires the extra features of the WS-* stack, you're probably best using RESTful services. WCF has full support for publishing and using RESTful services, and integrating with them is easy enough for any platform/technology.

---

great call on RESTful services... definitely gets rid of the bloat soap would cause

Quote:

---

Originally Posted by Bugbyte

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.

---

Not sure how next track and play fit in here?? As far as standardized why not just use SMIL 3.0 (already supported by all the major media players and can be transported as is).

Quote:

---

Originally Posted by VegasGuy

Although not as architecturally sophisticated as the effort described here, I've been running several prototype plugins on Centrafuse3 that provide live traffic, traffic cameras, RSS feeds, weather, Google calendar, location-aware search, personal notes and assorted streamng media. All of the information is derived from web-based APIs of one form or another.

If your effort is to try and aggregate information and resources relevant to a carPC users, and present it as an RSS/REST/Web Service/XMLRPC feed....its already being done. Almost all of Google, Yahoo and Microsoft's services are available as APIs. Trafficland, BeattheTraffic.com and others provide real-time traffic updates, EVERYBODY has an RSS feed nowadays. What's the difference between writing a plugin that accesses your service and writing one to access Yahoo?

What is the value added?

VegasGuy

---

The user is Free to use a client-plugin that talks with any webservice whether it be one from google or one provided by the OpenIVI service. The client assembly is Open so that it can be used by All platforms. That way OpenMobile just has to implement the interface and create UI around it as opposed to write all the web service bits himself AND the UI interface. To me that makes it valuable to all existing software platforms which should encourage platform developers to use it and contribute to it.

RESTful would be my other suggestion. I'm okay with that.

Quote:

---

Originally Posted by justchat_1

Not sure how next track and play fit in here?? As far as standardized why not just use SMIL 3.0 (already supported by all the major media players and can be transported as is).

---

No need to reinvent the wheel. A quick view of SMIL shows that it would probably work for multimedia, which is great.

What about when other stuff gets added, like OBDII codes or MAF values? I just want to make sure that these can be added to the exchange of information without having to extend something like SMIL.

Quote:

---

Originally Posted by kev000

The user is Free to use a client-plugin that talks with any webservice whether it be one from google or one provided by the OpenIVI service. The client assembly is Open so that it can be used by All platforms. That way OpenMobile just has to implement the interface and create UI around it as opposed to write all the web service bits himself AND the UI interface. To me that makes it valuable to all existing software platforms which should encourage platform developers to use it and contribute to it.

---

Implementing the interface and writing an rss parser are about the same...the advantage has to be the value of the available services. So far what i've seen (im talking about unique services):
* Online Playlist management
* Music Sync Services (i would stay away from calendar and that area as its well covered by google)
* Vin and DTC lookup
* Online FE configuration (settings management)

what else can we add to the list thats unique?

Seems like one advantage would simply be the ability to add the services themselves.

How about messaging services? That is, communications to the user from apps that are not necessarily running on the car PC? Receipt and transformation of text messages to audio, perhaps. Or correlation between your car's speed and a posted speed limit database with an audio warning when you are over that speed.

Location based services that process data based on your position and the status of your car? Perhaps a way to transfer trip information planned on the web or desktop to the car seamlessly?

Auto-trace relays to OpenStreetMap.org without user intervention.

I think the web configuration is one of the most powerful features. I like setting new radio stations in Pandora on my desktop pc and having them magically show up on my iPhone. Even if the configuration takes place on the desktop, relaying it for storage and sharing if you load up on another PC would be great.

You guys may be missing the point. Sure unique services will be a great value-added feature, but I think the strength of doing this is to consolidate all the APIs on the web into a single API rolled into one. See below for what I mean.

By doing this, everyone has access to the same APIs, no matter what front-end. We can format the data and standardize it. Also, the server can do most of the work instead of an already over-worked carputer.

If you have ever worked with the google API as I have, you will know that much work is required to get at the data that is needed. I say let the server retrieve the data, strip away what isnt needed, and then send a condensed file over the 3G connection. This will speed up data transfers and also be much better for those people who have bandwidth restrictions.

Here is what I mean in picture format.

http://www.mp3car.com/vbulletin/imag...c394993220.png

BTW... me and kev000 have been working together to develop this for our own project. Seems he wants to go public with it and make this open-source. I do have some code right now that does the following things:

1. Syncs a trip database between client and online DB (100% complete)
2. Syncs a POI database between client and online DB (100% complete)
3. Searches google maps based on current GPS location (90% complete)
4. Searches google maps by another address and/or zip code (90% complete)

The code for the google search may not be pretty, but it works quite well. The syncing between client and online DB allows for an unlimited amount of clients to connect and edit the data. This means thats you could create a trip online, hop in your car, and it would download when your car syncs online.

Quote:

---

Originally Posted by Nextabyte_Matt

You guys may be missing the point. Sure unique services will be a great value-added feature, but I think the strength of doing this is to consolidate all the APIs on the web into a single API rolled into one. See below for what I mean.

By doing this, everyone has access to the same APIs, no matter what front-end. We can format the data and standardize it. Also, the server can do most of the work instead of an already over-worked carputer.

If you have ever worked with the google API as I have, you will know that much work is required to get at the data that is needed. I say let the server retrieve the data, strip away what isnt needed, and then send a condensed file over the 3G connection. This will speed up data transfers and also be much better for those people who have bandwidth restrictions.

Here is what I mean in picture format.

http://www.mp3car.com/vbulletin/imag...c394993220.png

BTW... me and kev000 have been working together to develop this for our own project. Seems he wants to go public with it and make this open-source. I do have some code right now that does the following things:

1. Syncs a trip database between client and online DB (100% complete)
2. Syncs a POI database between client and online DB (100% complete)
3. Searches google maps based on current GPS location (90% complete)
4. Searches google maps by another address and/or zip code (90% complete)

The code for the google search may not be pretty, but it works quite well. The syncing between client and online DB allows for an unlimited amount of clients to connect and edit the data. This means thats you could create a trip online, hop in your car, and it would download when your car syncs online.

---

Not missing the point....disagreeing with your assumptions. For those of us that already have these features implemented, having to reimplement them just so they're formatted the way you prefer has little value.

One big issue that your overlooking is that the server can only act to reformat data, not store it in any way as this would violate the TOS. Like i've said before reinventing the wheel will have little value to anyone, if you want a service that someone other then you will use it needs to provide benefits not available elsewhere. Why would anyone rely on a single server to provide a reformatted google api when you can just get it from google directly?! (and know the service will never be down).