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
_______________________________________________
MeeGo-ivi mailing list
[email protected]
http://lists.meego.com/listinfo/meego-ivi

Reply via email to