Announcement

Collapse
No announcement yet.

OSDash Linux Client

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    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).
    Originally posted by ghettocruzer
    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

    Comment


    • #3
      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.

      Comment


      • #4
        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?
        Originally posted by ghettocruzer
        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

        Comment


        • #5
          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:
          Click image for larger version

Name:	screenshot1.png
Views:	1
Size:	5.3 KB
ID:	2276765

          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:
          Click image for larger version

Name:	screenshot2.png
Views:	1
Size:	9.5 KB
ID:	2276766

          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:
          Click image for larger version

Name:	screenshot3.png
Views:	1
Size:	6.5 KB
ID:	2276767

          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:
          Click image for larger version

Name:	screenshot5.png
Views:	1
Size:	12.8 KB
ID:	2276768

          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.

          Comment


          • #6
            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?
            Originally posted by ghettocruzer
            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

            Comment


            • #7
              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.

              Comment


              • #8
                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?
                Originally posted by ghettocruzer
                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

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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)?
                    openMobile - An open source C# Front End (why choose openMobile?)
                    - Always Recruiting Developers -
                    Like what you see? Donations are always welcome

                    Comment


                    • #11
                      Originally posted by justchat_1 View Post
                      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)?
                      I agree, the Single Library provided by OSDash is the way to go. For the Linux system though it makes sense to use that single library in a plug-able process. We've written the OpenICE components to be as frontend agnostic as possible. That's why fbd, proximity, and obdgpslogger are all separate processes. Furthermore, non-OpenICE stuff like Network-manager, oFono, bluez, gpsd, etc are also their own processes. So this OSDash Client implementation will basically be just an aggregation tool for a whole bunch of separate and relevant processes.

                      Like I said earlier, it may make sense for RR and CF, etc to interface with the OSDash Client Library directly instead of going through a separate process/abstraction layer.

                      This Linux Client really only fits the OpenICE model. For Crossplatform FE like OpenMobile, or Revfe, they may want to follow the path that keeps them crossplatform. Which will probably be implementing the Client library directly in their own plugins.
                      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.

                      Comment


                      • #12
                        openice osdash git repo

                        I've created a code repo for the osdash linux client. right now it just has some stub/example code. More to come later. You can check it out of git via:

                        Code:
                        git clone http://archive.openice.org/repos/osdashclient
                        I've repented a few things I originally planned. I think I will do the client in c++/Qt as either a library or a daemon/dbus-service. I haven't quite decided yet...
                        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.

                        Comment


                        • #13
                          Very cool, Kev! I was talking to OptikalFX about getting around to doing something with OSDash as we'd lost momentum.

                          I'll take a look at the sample code and come up with some stupid questions to ask.
                          Originally posted by ghettocruzer
                          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

                          Comment


                          • #14
                            Originally posted by Bugbyte View Post
                            Very cool, Kev! I was talking to OptikalFX about getting around to doing something with OSDash as we'd lost momentum.

                            I'll take a look at the sample code and come up with some stupid questions to ask.
                            Yeah, we did lose some momentum. Hopefully we can pick it back up. I'm hella-busy with life and haven't had much time for any off-work-coding.

                            Right now the example code points to the nextabyte server that matt is using to test on. Hopefully we can get the server back up and start testing in real life.
                            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.

                            Comment

                            Working...
                            X