[Development] [Proposal] Future QtSerialPort with plugins architecture

[Denis Shienkov]

Hi, folks,

I would like to discuss new idea of transition of QtSerialPort to
an architecture with the plug-ins/backends.

The reason is that we can use different approaches on different
platforms to enumerating a list of available devices, and to
implementing a code of I/O engine.

It will simplify a code and its maintenance for developers,
and also will provide flexibility for users.

= QSerialPortInfo =

For example QSerialPortInfo::availablePorts() can be made with,
different ways, which I suggest to divide into plug-ins/backends:

* on Windows : [setupapi], wmi, generic
* on WinCE      : [devmgr]
* on Linux        : [udev], sysfs, generic
* on OSX          : [iokit], generic
* on FreeBSD   : [sysctl], generic
* on QNX         : [generic?]
* other Unix    : [generic]

where [...] means that this plugin is preferred/default for this platform.

The user can use/change desired plugin, e.g. via the
QT_SERIALPORTINFO_PLUGIN environment, or via command line e.g.:

{code}
set QT_SERIALPORTINFO_PLUGIN=wmi // on windows
myapp.exe
{code}

{code}
export QT_SERIALPORTINFO_PLUGIN=sysfs // on linux
myapp
{code}

{code}
myapp -qspi sysfs // on linux
{code}

and so on, similar to the Qt's platform backends, like this:

* http://doc.qt.io/qt-5/embedded-linux.html

Currently we have mess-up (mixing-up) multiple approaches in one
implementation file, via ifdefs and so on, that is looks funny/hard, e.g,:

* on Windows : setupapi + generic
* on Unix         : udev + sysfs + generic

= QSerialPort =

Here also can be divided to the plugins/backends. E.g. some vendors
provides own HW chips which is RS232/485/TTL on the physical layer,
but has own vendor-specific API. An example it is FTDI chip with the
D2XX API, that is non-standard "serial port" API.

In this case the user can choose desired plugins via other
QT_SERIALPOR_PLUGIN environment, or via other command line, e.g.:

{code}
set QT_SERIALPORTINFO_PLUGIN=ftdi
set QT_SERIALPOR_PLUGIN=ftdi
myapp.exe
{code}

{code}
myapp.exe -qspi ftdi -qsp ftdi
{code}

Currently, I don't like the current implementation of internal architecture
of QtSserialPort where the code contains mix from different approaches
and so on, that is hard and ugly, IMHO.

So, dear community/developers/gurus, what do you think about? :)

BR,
Denis