Discussion:
vehicle communications and nobdy
Kevron Rees
2011-10-13 22:42:40 UTC
Permalink
I've made some pretty serious updates to nobdy based on feedback from
meego conf and the new branch is nearly ready to merge into master. I
thought I'd shoot an email to this list to update those who are interested.

New features:

(note: I use the words, 'provider' and 'subscriber' throughout the
feature list. These are nobdy-terms that describe plug-ins that
'provide' data to the bus and plug-ins that 'subscribe' to such data, do
something useful with it.)

I. Nobdy now supports multiple providers. This is mainly for developers
and testers developing applications using nobdy, but it could also be
used for enthusiast as well. The previous version of nobdy only
supported one provider. That means if the provider didn't support the
data you need in your application, you'd have to modify it. Now you can
mix multiple mini-providers to give you the supported data you need.
For example, if your vehicle or test hardware doesn't have gps, you can
attach a usb gps receiver and plug in the provider for that. Same thing
will accelerometer data.

II. Updated Tcp provider and subscriber. I've put a lot of effort into
vamping up the tcp socket provider and subscriber plugins. They now use
a simple javascript protocol. These providers allow distributed
environment where you can have nobdy on a phone hook up with another
instance of nobdy in the vehicle over a network connection. I've put
more focus on the tcp subscriber than the dbus subscriber because I
believe performance will be better and sockets support many more
flexible environments than dbus.

III. Websockets. The tcp subscriber supports a "websocket" option so
that you can connect to nobdy from an html5 application. This makes
nobdy "tizen-ready" out of the box. And because nobdy uses a javascript
protocol, hooking up with nobdy and parsing the data in a web
application is brain-dead simple.

IV. Logger and Logger Provider. In addition to the logger subscriber,
there now is a logger provider you can use to "play back" previously
logged sessions. This is great for testing because you no longer have
to use another application to feed data into nobdy. You can play back
your logs!

V. Supported codes. I've implemented support for many of the
suggestions on the Meego vehicle network api wiki page. It's really
easy to add more support so I imagine adding more and more as needs
arise. In this new version, the PIDs are ridged types instead of magic
strings. This promotes security and puts more of the burden on the
provider to know the specific vehicle protocols and pids. It also makes
it easier for developers as they don't have to memorise specific codes.

I admit that I haven't been following the Qt-ivi development in meego
for a while. Is there code available yet? At any rate, I think that
nobdy could easily fit in with whatever stack Tizen goes with or nobdy
could be the entire stack. A nobdy-provider could be written to hook up
to that and then nobdy can go about presenting the data in useful ways
to applications. It would in the very least be useful tool for development.

On another topic... Is there a tizen-ivi list now?

cheers,
Kevron

Loading...