Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: OSDash Linux Client

  1. #1
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,494

    OSDash Linux Client

    Thought I'd open up a thread for the Linux client. The Linux client will consist of a c++ (Qt based) daemon that consumes the web service and exposes access methods over dbus.

    The daemon will be pluggable so you can add more "providers" later on. A "provider" is a new web service to be consumed.

    I think I'll name it OCD for OSDash Client Dash.
    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. #2
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,359
    Blog Entries
    2
    Will you be able to tell the client to take certain actions? Let's say you have a service that allows you to control the Fusion Brain from a web page. You command it to unlock your doors, the service notifies the client of a request to trigger a relay and then how does that get to the Fusion Brain control app on the computer?

    Or would it work that way?

    I ask, because I'd like to be able to tune the BoomzBox HD, change the channel on my XM direct and also control Fusion Brain stuff -all from either a web page or even a Front End that isn't necessarily running on that computer (e.g. the hardware stuff is on a Sheeva plug, the software FE is on a separate PC).
    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

  3. #3
    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 Bugbyte View Post
    Will you be able to tell the client to take certain actions? Let's say you have a service that allows you to control the Fusion Brain from a web page. You command it to unlock your doors, the service notifies the client of a request to trigger a relay and then how does that get to the Fusion Brain control app on the computer?

    Or would it work that way?

    I ask, because I'd like to be able to tune the BoomzBox HD, change the channel on my XM direct and also control Fusion Brain stuff -all from either a web page or even a Front End that isn't necessarily running on that computer (e.g. the hardware stuff is on a Sheeva plug, the software FE is on a separate PC).
    I guess in that case the client plugin that would talk to the fusion brain web service would also talk to the fusion brain daemon directly.
    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.

  4. #4
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,359
    Blog Entries
    2
    Right, so I guess what I'm wondering is how do you tell the client to direct it's output, or "talk" to the app? Let's change the example and say the web service wants to use obdgpslogger and query the capabilities of your car's OBDII port. The terminal command would be:

    obdgpslogger -p

    Would the client receive that command from the web service and pass the command on to the obdgpslogger application? Could it also return the information to the web service?
    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. #5
    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 Bugbyte View Post
    Right, so I guess what I'm wondering is how do you tell the client to direct it's output, or "talk" to the app? Let's change the example and say the web service wants to use obdgpslogger and query the capabilities of your car's OBDII port. The terminal command would be:

    obdgpslogger -p

    Would the client receive that command from the web service and pass the command on to the obdgpslogger application? Could it also return the information to the web service?
    I guess I should describe more what I'm thinking. The following cheap diagrams describe consumption of a web service designed to get obd capabilities. I haven't decided on which approach is best yet, but these are the options:

    Diagram 1:
    Name:  screenshot1.png
Views: 307
Size:  5.3 KB

    In this example, the plugin talks to the webservices, handles any parsing and then exposes the exact same interface as the web service over dbus. This works when the FE needs to talk to the web service in a simplified manner.

    Diagram 2:
    Name:  screenshot2.png
Views: 330
Size:  9.5 KB

    This shows some sort of intermediate app that consumes the dbus interface provided by Diagram #1, and then directly integrates with obdgpslogger. This IMHO, is a very expensive way to do things.


    Diagram 3:
    Name:  screenshot3.png
Views: 320
Size:  6.5 KB

    In this example, the plugin talks to the web service and directly with the application. This makes the plugin very platform specific, but is the simplest approach.

    Diagram 4:
    Name:  screenshot5.png
Views: 319
Size:  12.8 KB

    This example is the best of all worlds. Depending on interest level, a .NET client assembly (dll) can be provided by OSDash to abstract the consuming applications away from any parsing and communications setup that would normally occur. OSDash provides a library that the plugin loads, the plugin calls some nice pre-made methods, and exchanges the information with the platform. In our example, the plugin would use the assembly and talk directly with obdgpslogger (or fusion brain, or whatever).

    This is why I propsed that OSDash provide *at least* a thin client assembly that would provide convenience methods to consumer applications like the frontend directly, or the Linux client. It's only worth developing a cross-platform client library if FE devs think it's valuable. Initially, I get the impression that it may not be useful to FE developers. But we haven't heard opinions from everyone yet. so depending on that decision, I'll likely do either 3 or 4.
    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.

  6. #6
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,359
    Blog Entries
    2
    I think I'm confused by your use of the term plug-in. Do you mean a plug-in that is the OSDash client, or a plug-in that is a front end plug-in like a Centrafuse or Ride Runner plug-in?

    If you mean the plug-in is the OSDash client, then example 3 is how I envisioned it, which is probably why just_chat is confused when I mentioned that the clients have to be OS specific. And number 4 is probably a good longer term goal. I presume that if you do 3, you can always add the library abstraction in a version 2 or 3 or whatever, right?
    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. #7
    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 Bugbyte View Post
    I think I'm confused by your use of the term plug-in. Do you mean a plug-in that is the OSDash client, or a plug-in that is a front end plug-in like a Centrafuse or Ride Runner plug-in?

    If you mean the plug-in is the OSDash client, then example 3 is how I envisioned it, which is probably why just_chat is confused when I mentioned that the clients have to be OS specific. And number 4 is probably a good longer term goal. I presume that if you do 3, you can always add the library abstraction in a version 2 or 3 or whatever, right?
    Right, it is a OSDash client plugin. Depending on how I do it, 4 could be difficult if I don't do it up front. I was planning on writing the client in Qt/c++ if I were to do 3 or in c#/.NET if I were to do 4.

    I'm leaning towards 4 just because abstracting will be less of a headache later on.
    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.

  8. #8
    Admin. Linux loser.
    Auto Apps:loading...
    Bugbyte's Avatar
    Join Date
    Sep 2004
    Location
    Corning, NY
    Posts
    7,359
    Blog Entries
    2
    Okay, then 4 sounds like the right way to go. Can we refer to the OSDash client as a client instead of a plug-in? I realize that you could probably write a plug-in for, say, Ride Runner, that would interface with the services, but can we put that aside and just call it the OSDash client?
    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. #9
    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 Bugbyte View Post
    Okay, then 4 sounds like the right way to go. Can we refer to the OSDash client as a client instead of a plug-in? I realize that you could probably write a plug-in for, say, Ride Runner, that would interface with the services, but can we put that aside and just call it the OSDash client?
    Yes. I think we should define some terms so we are all on the same page. The "OSDash Client" should be the cross platform library used by the platform to communication with the web services. The platform specific part may be a RR plugin that uses the OSDash client directly, or it may be a service daemon that supports it's own plugin architecture like in the case of Linux. The sooner we have clear definitions, the better off we'll be.
    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. #10
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    1,783
    Yea 4 is the way to go if you want to keep this open....

    Were you still thinking of services as a plugin based architecture or are we going with the single library approach (which I think makes more sense)?

Page 1 of 2 12 LastLast

Similar Threads

  1. New Frontend for Windows and Linux
    By gbr in forum Other Cool Front Ends
    Replies: 68
    Last Post: 01-21-2009, 08:55 PM
  2. Linux duck duck goose!
    By rocken in forum Linux
    Replies: 11
    Last Post: 03-12-2006, 11:15 AM
  3. The LOW Risk Linux Adventure...
    By grepzen in forum Software & Software Development
    Replies: 13
    Last Post: 11-08-2004, 09:12 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
  •