Propose: more organization

[ftonello]

Guys,

I'm happy to see a nice amount of work in this plugin. It shows that's useful to a lot of people. I can surely say for the company I work for.

Anyway, what I want to discuss is the various changes that we have in this plugin. Some of them changes a lot of the way end-users (usually qml applications) would you the plugin.

I really think we need to define our goals, use cases that the plugin should support, clean and nice API, milestones to reach those goals then tagging the version, and so on.

I think we are a little bit disorganized. This may be a reason why there is another guy working in another connman library by him self instead of contributing here https://bitbucket.org/devonit/qconnman. (BTW he has some code from us)

What do you guys think? I hope can all discuss here and come up with a consensus.

[lpotter]

Hi,
I should have introduced myself. I worked for Trolltech 2003-2008 on Qtopia (Brisbane Australia office) when Nokia took over (QtMobility/MeeGo/Qt), and then until last year when Nokia let all the Brisbane office go. Now I find myself doing work for Jolla on Mer, Nemo and Sailfish. I am the maintainer for QtSensors, QtSystemInfo, as well as sensors, systeminfo in qtmobility. (and also the Qt bearer connman/ofono, and mac os x code)

Perhaps we could have a channel at freenode?

I agree we should try to agree on direction, etc.

Not sure why there is another connman/qt project.

[ftonello]

@rojkov @rburchell @pascal-bach What do you guys also think?

[ftonello]

Guys, just for the record. My patch with a libconnman-qt openembedded recipe is in upstream now.
http://cgit.openembedded.org/meta-openembedded/commit/?id=f4052df881190557b8037d15bd1cdf54bacf96ca

This is one more reason why we should have more direction, so we don't break peoples stuff.

[lpotter]

Sure, we should try and not break things. The qml stuff is new, and needs to be worked so it is usable. Sometimes, things need to be changed in the library to make it work better for qml.

[ftonello]

@lpotter Also our tags does not match the plugin version. Which is confusing.

[lpotter]

I just use tags for our packaging, the makedist script uses the latest tag to create a tarball. We can change them to whatever, it doesn't really matter to me.

[rojkov]

Sorry, I was busy with other tasks lately.

So... the reason why this library has ended up in Nemo was that

1. Intel discontinued development of the Qt bindings to connman;
2. libconnman-qt got orphaned and became incompatible with the latest connman (that's why I bumped up plugin's version to 0.2);
3. we (in Jolla) needed Qt interface to connman, but had no wish to maintain our own flavour of it.

Our needs are

1. compatibility with the latest version of connman whose API still evolves and is not very QML friendly;
2. more or less stable QML plugin;
3. compatibility with Qt4.

Thus I decided to keep library API very close to connman's D-Bus API (because this what users usually expect from a wrapper library) and to put adaptor logic to the QML plugin.

I assumed that there is no reason to instantiate NetworkServices and NetworkTechnologies declaratively because it would require additional D-Bus requests (NetworkManager initializes instances of NetworkServices with their properies set) and that additional synchronous calls (marked as Deprecated in connman's docs by the way) to D-Bus are more expensive than an additional abstraction layer.

If I wanted to instantiate services declaratively I'd probably add one more declarative class for that.

Now I see that Lorn wants to move the logic in the opposite direction. IMHO this will make things a bit messy though I like the part with synchronous initialization of NetworkManager as this will help to get rid of some timing issues. But... libconnman-qt is the first project where I started to use C++ and Qt. Feel free to ignore my opinion.

That was about our use cases and API we need. I don't really care of version tagging. If you feel it's important then I'd propose to bump up the version of the plugin to 1.0 and the library version to 1.0.0 and to tag minor releases as 1.0.x (it's easier to update tarballs in Nemo's OBS this way).

The thing I care about a bit more is the coding style. I'd propose to agree on some conventions like no tabs, 4 spaces indentation, no Qt specific keywords.

We may use Nemo bugzilla to set goals and to track progress.

[jeremiah]

Hi,

I'm the community manager for GENIVI. We use a lot of the technologies you guys are working on and a lot of GENIVI members use Qt. (GENIVI is open source automotive software.)

I wonder if there is room for more collaboration between the folks here and the projects they're working on and GENIVI? There is going to be an automotive devroom at FOSDEM where we're going to talk about things like systemd to connman interface, etc. Maybe some of you guys and gals will be there?

In any case, if anyone wants to talk more about collaboration, please fire a ping to jeremiah.foster AT pelagicore.com

Thanks,

Jeremiah