Printable View
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.
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.Quote:
Originally Posted by Bugbyte
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:Quote:
Originally Posted by Bugbyte
Diagram 1:
Attachment 57487
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:
Attachment 57488
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:
Attachment 57489
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:
Attachment 57490
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.
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.Quote:
Originally Posted by Bugbyte
I'm leaning towards 4 just because abstracting will be less of a headache later on.
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.Quote:
Originally Posted by Bugbyte
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)?
