Moving libqmi-glib to fd.o's libqmi repo

[Aleksander Morgado]

Hey Marcel,

> 
>>> I looked deeply into all areas of QMI services. Trying to create a fully
>>> bloated library with API support for all services is a waste of time. At
>>> least for oFono it is useless. The problem is that QMI itself is deeply
>>> service context sensitive and there is no point in creating another
>>> abstraction on top of it. I decided to just put the service specific
>>> handling directly into the oFono drivers. Have a look at the code for
>>> yourself, it worked out super nicely for us.
>>
>> Sure it did, but we really want to have a library here, instead of 
>> having everyone implement the message-specific logic over and over.
> 
> I am still failing to see what this all buys you. You still need to
> understand what message input and output is available/required. You are
> just getting fancy accessor methods. And these come at the price of a
> larger binary size. If you look at QMI as something besides DMS and WDS,
> it is pretty large API.
> 

Not only fancy accessor methods. With this library, users do not need
know message/tlv id enums (neither know nor implement them); users do
not need to analyze and write packed structs to match input/output TLVs
themselves; users do not need to care of parsing arrays or
variable-length structs; users do not need to define enums themselves...
 Users instead will get all the raw protocol stuff already 'digested'
into a set of new types and methods (hopefully well documented at some
point), with built-in GError-based error reporting and built-in GIO-like
async method support. Of course, if you prefer to analyze and write
support for the protocol yourself, this library buys you nothing.

> And a small side note; so for QMI it has to be a library that is suppose
> to do everything. For AT commands it is then fine to redo things over
> and over again and use resource intensive regular expressions.
> 

You said that, not me :-)

> How many users of this library are you actually expecting? Since the QMI
> device exposed by the kernel can only be opened by one user at a time.
> 

Well, not everyone in the world is using the same connection manager.
This library is just trying to provide a common way to handle the
protocol for every connection manager interested, either directly in C
(e.g. ModemManager), with python via introspection (e.g. Wader), or even
with the 'qmicli' utility in shell scripts (e.g. the qmi4g protocol
handler in OpenWRT).

Cheers!

-- 
Aleksander