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

Printable View

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

12-06-2009, 08:40 PM
tripzero

Quote:

Originally Posted by justchat_1

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).

The service that matt is referring to for storing favorites and trips doesn't have to violate google's TOS. We are ways of accomplishing the goal without violating any TOS. But I won't go into details about that particular service at this time. I agree that wrapping "every existing service in one web service" may not be the best approach for OpenIVI. There are benefits to doing so as bugbyte and matt suggests, but it should be prioritized lower than other more important things if at all.

I think the client assembly is very important. Not as important as the services themselves, but having a unified plugin framework that spans platforms and frontends should be useful to everyone. The idea levels the playing field and allows innovation to grow in the directions it should: ease of use, perfect integration and awesome user interfaces (which IMHO, needs to be improved a lot if we want to be taken seriously). Sure it takes some advantage away from the frontends who have all these features implemented (which none really do at this point), but the advantages outweigh the disadvantages both to the platform and to the end-user.

Sure, CF may want to continue just developing using their own plugin arch and that's fine. It's really their loss. I'd like to imagine platforms which use this leapfrogging CF3 quite easily.

I think we should:

- Get basic services defined and code written
- Get basic web frontend
- Get basic backend up with plugin interfaces defined.
- Create plugins for the services that we have written

Update: I thought that I owned the "OpenIVI" project on sf.net but I was mistaken. The project that I did start was OpenICE.VIS, VIS meaning (Vehicle Infotainment Services).

Here's the project page:

https://sourceforge.net/projects/openicevis/

Anyone who's wanting to jump on board send me a line, You'll need a sf.net/yahoo/google account and I can give you commit rights to the repo. Maybe we can get a subforum for this project as well so we can facilitate communication.
12-06-2009, 09:43 PM
justchat_1

Quote:

Originally Posted by kev000

The service that matt is referring to for storing favorites and trips doesn't have to violate google's TOS. We are ways of accomplishing the goal without violating any TOS. But I won't go into details about that particular service at this time. I agree that wrapping "every existing service in one web service" may not be the best approach for OpenIVI. There are benefits to doing so as bugbyte and matt suggests, but it should be prioritized lower than other more important things if at all.

I think the client assembly is very important. Not as important as the services themselves, but having a unified plugin framework that spans platforms and frontends should be useful to everyone. The idea levels the playing field and allows innovation to grow in the directions it should: ease of use, perfect integration and awesome user interfaces (which IMHO, needs to be improved a lot if we want to be taken seriously). Sure it takes some advantage away from the frontends who have all these features implemented (which none really do at this point), but the advantages outweigh the disadvantages both to the platform and to the end-user.

Sure, CF may want to continue just developing using their own plugin arch and that's fine. It's really their loss. I'd like to imagine platforms which use this leapfrogging CF3 quite easily.

I think we should:

- Get basic services defined and code written
- Get basic web frontend
- Get basic backend up with plugin interfaces defined.
- Create plugins for the services that we have written

Update: I thought that I owned the "OpenIVI" project on sf.net but I was mistaken. The project that I did start was OpenICE.VIS, VIS meaning (Vehicle Infotainment Services).

Here's the project page:

https://sourceforge.net/projects/openicevis/

Anyone who's wanting to jump on board send me a line, You'll need a sf.net/yahoo/google account and I can give you commit rights to the repo. Maybe we can get a subforum for this project as well so we can facilitate communication.

Not sure why I mentioned tos there...i think that was supposed to be a separate thought but it sounds like you understood what i was going for.

I think those steps are exactly what should come next. Maybe the second and third at the same time but pretty much that order. Not sure if I mentioned this before but one of the core points of the system should be that services are not limited to a single host. This should allow for mirrors to be setup and services hosted on different servers to work seamlessly for the end user.

Oh and maybe OpenVIS instead of OpenICE.VIS :p
12-07-2009, 08:32 AM
Bugbyte
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:

Syncs a trip database between client and online DB (100% complete)
Syncs a POI database between client and online DB (100% complete)
Searches google maps based on current GPS location (90% complete)
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.
This is along the lines of what I was thinking. Do a lot of the processing online and relay the stuff you need to the car when/if it needs it.
12-07-2009, 12:59 PM
Bugbyte

Just had a call with mp3car. They like this project and want to see it succeed. They're willing to provide the following:

1. Server space
2. User I.D. integration
3. Web app development to configure the server app. We talked about making the web app part open source and they seemed to agree.

I told them to contact you, Kev and get some more clarity on where they can help. It's important to get everyone on the same page if we are going to be successful.
12-07-2009, 06:55 PM
justchat_1

I think we're still on step 1...defining the architecture. Once thats done we can break up defining of the individual services. Looking at whats on the list i'll probably take half of them and kev will take the other half. After that, then we work on actually implementing all that goodness, and well need to work with mp3car on getting the server space up and configured.
12-10-2009, 09:07 AM
Bugbyte

Idea for service:

Crowdsourced OBDII pids.

Service would receive and serve pids for different car makes and models. Users can upload pids to the server automatically and receive a list of pids with definitions, if available. Web interface would include a way to tag pids with their meanings. Basis for pids would be the project on mp3car that has an app and is building a database that accomplishes the same thing.

Service would mainly store the pid file locally, if applicable, and could be informed of updates to the file if they exist. I would then download the update.

File location should not be fixed or required. That is, if a user wants to dynamically check for the pid meaning each time, the service should allow this.
12-10-2009, 09:55 AM
justchat_1

Quote:

Originally Posted by Bugbyte

Idea for service:

Crowdsourced OBDII pids.

Service would receive and serve pids for different car makes and models. Users can upload pids to the server automatically and receive a list of pids with definitions, if available. Web interface would include a way to tag pids with their meanings. Basis for pids would be the project on mp3car that has an app and is building a database that accomplishes the same thing.

Service would mainly store the pid file locally, if applicable, and could be informed of updates to the file if they exist. I would then download the update.

File location should not be fixed or required. That is, if a user wants to dynamically check for the pid meaning each time, the service should allow this.

Read my last post on page one....

Quote:

Originally Posted by justchat_1

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 :)
12-10-2009, 10:05 AM
Bugbyte

Doh! I knew I must have seen that somewhere. Sorry about that!
12-10-2009, 10:13 AM
tripzero

Along the same lines, i think it'd be useful to keep statistics on what kind of trouble codes people get and associate that with a model/make/year. Users can then look at the data and identify future trends for their vehicle.
12-10-2009, 11:39 AM
justchat_1

Quote:

Originally Posted by kev000

Along the same lines, i think it'd be useful to keep statistics on what kind of trouble codes people get and associate that with a model/make/year. Users can then look at the data and identify future trends for their vehicle.

Can't seem to find the link but one of the obd manufacturers did exactly that and published the top few from every manufacturer. Theres also a DMV report of the top ten for each manufacturer from every year. I used that initially to build the trouble code descriptions (to make sure I got the most common ones).

Quote:

Originally Posted by Bugbyte

Doh! I knew I must have seen that somewhere. Sorry about that!

No problem, I do it all the time...good thing theres an edit button lol

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