QtService replacement

[kshegunov]

@SGaist
An SMS gateway. Basically middleware standing between a PHP based (I believe) system and an AT modem (a simple GSM). I have most of the communication code - it communicates with the websystem through XML, parses that and then communicates with the modem through AT commands. It used to be running on Windows and the client now requires it ported to Linux. It was some years since I had developed it though (I think Qt 4.6 was the version I had used then) and I'm about to rewrite some parts.

[SGaist]

Sounds nice !

Do you need it as an "independent" daemon or would a DBus service be good ?

[kshegunov]

@SGaist said:

Do you need it as an "independent" daemon or would a DBus service be good ?

I'd prefer to not use DBus in case the client decides at some point to migrate back to Windows. Not that it wouldn't put me in a similar predicament, but I suppose it'd be easier to change the used underlying API.

[SGaist]

I haven't tested it yet but IIRC DBus has integrated the code to run on Windows. Qt now also build the module for this platform.

[kshegunov]

@SGaist
This is the first I hear of it. Doesn't this mean that there should be some kind of service actually providing the d-bus functionality on windows?

[SGaist]

It's described here.

Probably something like dbus-daemon.

[kshegunov]

Certainly interesting, I might check it out.

[kshegunov]

So, finally I have a working Linux implementation. The application object uses (as suggested) the D-Bus for control. It's a work in progress, as it can be seen from the missing Windows implementation (although I have some old code that would be refactored).
There's still the need to provide some template init.d script and dbus configuration file in a user-friendly manner (i.e. to actually implement the install and uninstall options) but it is a start.

Source can be found here: https://bitbucket.org/kshegunov/qtdaemon

Usage is simple:
Without command line arguments is the daemon process itself.
With command line arguments is the controller process. The planned switches are for starting, stopping, installing and uninstalling, and of course help (-h/--help).

The application object emits daemonized() when the daemon (process) has initialized itself.
started(), stopped(), installed() and uninstalled() are emitted from the application when running as controller to the daemon and are somewhat self-explanatory.

Sot, that's for now. Further down the road when (hopefully) things get more complete I'll put a post in the "Showcase" section.

As usual, comments, suggestions, critiques, thoughts, any and all feedback is greatly appreciated!

[SGaist]

Looks good :)

The only thing that surprises me is the width of the white spaces ^^

[kshegunov]

@SGaist

The only thing that surprises me is the width of the white spaces ^^

Aaah, don't start me on your Qt use-spaces-instead-of-tabs style ... I'm too old to change habits so drastically (no C++11 in that code either). :)

[SGaist]

Even if no C++11 used, Q_DECL_OVERRIDE would be a nice addition :) (something I can contribute if you want)

[kshegunov]

@SGaist
That's syntactic sugar, but I suppose I could add a few override specifiers and convert the NULLs to nullptr (I think some of the D-Bus API I use was introduced in Qt 5.5, so C++11 would practically be implicit). That'd be the easy part. I envision a problem with OSX, with which you can help if you have the time. I have no idea what infrastructure there is on OSX to have daemons, how they're managed ... or practically anything about that OS ... I've never worked with that system. The only thing I know it's UNIX based/like and that's all. :D

[kshegunov]

@SGaist
Well, I followed your suggestion and have used override and nullptr at the appropriate places (removed the virtual as well). I also have added the template scripts, implemented the --install, --uninstall options and as a whole I managed to finish the Linux implementation. Also I decided to add one --fake command line option that allows the daemon process to be debugged (it doesn't start the backend thus is not detaching from the terminal, it still emits the daemonized() signal though).

More suggestions and comments are (still) welcome.