Page 4 of 7 FirstFirst 1234567 LastLast
Results 31 to 40 of 62

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

  1. #31
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,494
    Quote Originally Posted by justchat_1 View Post
    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.
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  2. #32
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    Quote Originally Posted by kev000 View Post
    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

  3. #33
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,359
    Blog Entries
    2
    Quote Originally Posted by Nextabyte_Matt View Post
    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.



    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.
    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.
    Quote Originally Posted by ghettocruzer View Post
    I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
    Want to:
    -Find out about the new iBug iPad install?
    -Find out about carPC's in just 5 minutes? View the Car PC 101 video

  4. #34
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,359
    Blog Entries
    2
    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.
    Quote Originally Posted by ghettocruzer View Post
    I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
    Want to:
    -Find out about the new iBug iPad install?
    -Find out about carPC's in just 5 minutes? View the Car PC 101 video

  5. #35
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    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.

  6. #36
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,359
    Blog Entries
    2
    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.
    Quote Originally Posted by ghettocruzer View Post
    I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
    Want to:
    -Find out about the new iBug iPad install?
    -Find out about carPC's in just 5 minutes? View the Car PC 101 video

  7. #37
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    Quote Originally Posted by Bugbyte View Post
    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 View Post
    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

  8. #38
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,359
    Blog Entries
    2
    Doh! I knew I must have seen that somewhere. Sorry about that!
    Quote Originally Posted by ghettocruzer View Post
    I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
    Want to:
    -Find out about the new iBug iPad install?
    -Find out about carPC's in just 5 minutes? View the Car PC 101 video

  9. #39
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,494
    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.
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  10. #40
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    Quote Originally Posted by kev000 View Post
    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 View Post
    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

Page 4 of 7 FirstFirst 1234567 LastLast

Similar Threads

  1. Open GPS-Traffic Link Web Service
    By tripzero in forum Software & Software Development
    Replies: 0
    Last Post: 07-14-2008, 03:39 PM
  2. Pre-Release Thread: Frodo XM Service
    By frodobaggins in forum Software & Software Development
    Replies: 10
    Last Post: 08-04-2005, 04:10 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •